Re: Experimental patch: generating BKI revisited

On Fri, Nov 13, 2009 at 5:16 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> I had a look at this some time ago and I must admit that I find it
> pretty interesting. The technology choices make it
> obviously impossible to merge -- not only the particular Perl modules
> used, but the mere fact that Perl is used (and that such a recent
> version is required). But you're already aware of all this so I'm not
> going to say more.

Thanks for taking a look!

One thing I didn't mention is that the scripts that use Catalog.pm
were designed to be 5.6 compatible. A different catalog description
that didn't require Perl modules could be swapped in. As long as
Catalog.pm exported the same data structures, the logic wouldn't need
to change. The concern there would be cost of developing a format and
a parser to go with it. If it didn't make developers' lives
significantly easier, it wouldn't be worth it.

I haven't tried, but I think that the current system could be tweaked
to generate pg_attribute and schemapg.h without needing any
declarations in pg_attribute.h. I'll look into it.

> As far as the data file is concerned, I think having it all in a single
> file is a loser. I'd go for a file per catalog.

YAML aliases can only refer to anchors that precede it in the same
document. It does make the file frustratingly large, but
human-readable oids make up for it IMO.

> Also, I don't like the
> fact that the column descriptions are lost because of being in a
> YAML comment. I think it'd be better if the generated pg_foo.h files
> had them.

I considered that, but I wasn't sure the added complexity was worth it.

> One thing I loved about this is that it's trivial to add a column to
> pg_proc and that this not mean that I have to edit almost every single
> line of the damn monster file.

One could conceivably write a script against Catalog.pm that generated
DATA(); statements to copy and paste into a header file. It might be a
useful tool, if only for error checking. For that to be successful,
the YAML file would need to be kept up to date, incurring duplicate
maintenance.

John