Re: schemapg.h

On Wed, Aug 12, 2009 at 6:44 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> I think having schemapg.h be autogenerated is a good idea, so I stripped
>> that from Robert Haas' patch.  Here's the result.  This should be
>> relatively uncontroversial since, well, the controversial stuff has been
>> stripped.  The one problem is that it introduces more complex code than
>> it removes dull declarations.
>
> Indeed, and it fails to get rid of all the dull declarations :-(.
>
> I thought the idea was to generate all this stuff directly from the C
> struct declarations (plus some hardwired knowledge about the datatypes,
> comparable to what is in TypInfo in bootstrap.c already).  Removing four
> out of six Schema_pg_xxx macros while leaving the equivalent DATA
> declarations behind isn't my idea of a major step forward.

I never intended anything in this patch to be a major step forward.
It's so difficult to get agreement even on a minor step forward that
it is a waste of time to try for a major step forward. I can only
hope that we'll eventually be able to commit something out of all of
this, and that the discussion we have along the way will provide some
direction for future improvements. Personally, having relatively
recently gone through the pain of making changes to a bootstrap
catalog (for ALTER TABLE ... ALTER COLUMN ... SET STATISTICS
DISTINCT), I think reducing the number of places that have to be
updated from 2 to 1 is a BIG improvement. We can deal with getting it
down to 0 in a future patch.

Eliminating any DATA() lines at all is a big deal. It means that the
current way that we generate postgres.bki will no longer work; that
file will have to be generated by a script that has all the same
smarts as the script that generates the Schema_pg_* declarations.
That is why the patch that I submitted unifies ALL of the things that
look at DATA() lines into a single script, so that changes to the
logic only need to be made in one place. Although I'm happy to have
any portion of this work committed, I think that we should try hard to
move toward that as a goal, because I think it will open the door to
many future improvements.

> The patch as submitted also appears to turn Perl into a hardwired
> requirement for all Unix builds.  While I'm not necessarily averse to
> doing that, I'd like to get more results out of it than this.

I haven't looked at Alvaro's patch. Mine turned everything that was
generated by perl into a distprep target. The reasons why I thought
this was OK were discussed in the email in which I submitted the
patch.

...Robert