On Sun, Dec 20, 2009 at 7:20 PM, John Naylor <jcnay...@gmail.com> wrote: > Greetings, > > Following up on my experimental patch last month to revamp the BKI > infrastructure, I am proposing a less invasive set of changes with the > hope of offering something committable. Some of these were discussed > by Robert Haas and others last summer. > > 1. Remove all DATA() declarations from pg_attribute.h, since they are > easily generated. Introduce a new BKI pseudo-command > BKI_NAILED_IN_CACHE, which indicates that relcache.c needs a > Schema_pg_foo declaration for that catalog. Place these declarations > in a new header schemapg.h. This will reduce the effort to add or > change critical tables. > > 2. Use identical scripts on Posix and Windows systems, using Perl 5.6 > (no CPAN modules needed). The grepping of the catalog headers is done > by Catalog.pm, which gives the scripts gen_bki.pl and gen_fmgr.pl a > structured interface to the data. The pg_type info is saved so that > the relevant fields can be copied into those of pg_attribute. > > 3. Make the BKI files, fmgrtab.c, fmgroids.h, and schemapg.h distprep > targets, so distribution tarballs can still be built without Perl on > Posix systems. > > Feedback on the Makefile changes would be appreciated, since that was > the hardest part for me. The MSVC changes are untested.
This is really nice. I haven't done a full review, but it seems as if you've eliminated some of the more controversial aspects of what I did before, as well as done some good cleanup and refactoring. One minor nit is that I think we should end up with genbki.pl rather than gen_bki.pl, in the interest of changing nothing without a good reason. A more important point is whether we really need to make this dependent on Perl 5.6 or later. What features are we using here that actually require Perl 5.6? I suspect the answer is "none, but we don't like writing the code in a way that is backward compatible to crufty, ancient versions of Perl", to which my response is "get over it". :-) I always use the three-argument form of open() in all new code, but for fixed strings the two-argument form is just as good and has been supported for far longer. Any suggestions that we should prefer clean code over portability are, in my opinion, non-starters. Again, thank you for your work on this! ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
