Re: [HACKERS] LONG varsize - how to go on - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] LONG varsize - how to go on
Date
Msg-id 18624.945702561@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] LONG varsize - how to go on  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] LONG varsize - how to go on
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] LONG varsize - how to go on
Next
From: Bruce Momjian
Date:
Subject: Re: QUESTION: Replication