Re: schemapg.h
От | Robert Haas |
---|---|
Тема | Re: schemapg.h |
Дата | |
Msg-id | 603c8f070908121619p7e6569caha10c1e93d828555d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: schemapg.h (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: