Re: [HACKERS] LONG varsize - how to go on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] LONG varsize - how to go on
Дата
Msg-id 18624.945702561@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] LONG varsize - how to go on  (wieck@debis.com (Jan Wieck))
Ответы Re: [HACKERS] LONG varsize - how to go on  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
>     Would  be  best  for me if you can leave out the pgindent run
>     for this  release.  I  already  have  some  small  things  as
>     patches,  that  I  apply to the latest cvs update.

Why not do what Vadim is doing for XLOG: commit your changes under
#ifdefs for a symbol that isn't yet defined?

#ifdef LONG_ATTRSnew code
#elseold code
#endif

I think this'd possibly be helpful anyway for study and debugging
purposes, since people could easily see what you've changed and where.
Eventually, after all the dust settles, we can get rid of the #if's
and the old-code fragments.

I don't normally like #ifdef'd patches of this sort, but as a temporary
measure during implementation I think it'd be better than keeping a
private set of files.

>     And I fear
>     what's currently discussed about changing 4  column  tabstops
>     would break them completely.

Bruce doesn't want to do that, and I doubt anyone will force the issue
over his veto.  But it would be nice to be able to do a pgindent run;
there's a lot of new code in this release.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] LONG varsize - how to go on
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: QUESTION: Replication