Обсуждение: schemapg.h

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.

Ideally this would serve as a basis upon which the rest of the generated
stuff is built.  I think it would be good to have a module that contains
common code.  In particular we could move process_input_file() to it,
and pass function refs for each subblock.  That way each program could
be relatively short, and the regexes that parse the files would all be
in a single place.

Thoughts?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.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.

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.  And when
we do do it, it needs to be documented and enforced by configure.  Plus
we ought to get rid of the workarounds we have for not requiring Perl
for tarball builds.  Or, if people would prefer to continue not
requiring Perl, we'd need to make schemapg.h be one of the derived
files that's shipped in tarballs.

Lastly, it'd be nice if the comments in gen_schemapg.pl had some
resemblance to what it is actually doing, rather than talking about
a lot of stuff that was stripped out of it.
        regards, tom lane

On Wed, Aug 12, 2009 at 6:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.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

Tom Lane escribió:
> Alvaro Herrera <alvherre@commandprompt.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 :-(.

Right.  I don't think we're going to move forward if we only accept
giant steps at a time, and we simultaneously reject patches that are too
intrusive.  What this says is that we're going to need to accept that a
first change to the file generation system is going to be a dwarf step
forward; otherwise we're going to stay right where we arej with which
I'm not terribly happy.

> 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.

Hmm, perhaps that's workable.  I'll have a look around.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane escribi�:
>> Indeed, and it fails to get rid of all the dull declarations :-(.

> Right.  I don't think we're going to move forward if we only accept
> giant steps at a time, and we simultaneously reject patches that are too
> intrusive.

I'm okay with small steps as long as they're small steps in the right
direction ;-).  I'm not convinced that this script is the right
direction.

>> 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).

> Hmm, perhaps that's workable.  I'll have a look around.

OK.  It might be interesting to see if this can be unified somehow with
what the bootstrap.c code does.  (However, since that runs at initdb
time not during compilation, there may not be any reasonable way to
unify the two.)
        regards, tom lane