Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Peter Eisentraut wrote:
>> I don't think I like this. I know pg_proc.h is a pain to manage, but at
>> least right now it's approachable programmatically. I recently proposed
>> to patch to replace the columns proisagg and proiswindow with a combined
>> column prokind. I could easily write a small Perl script to make that
>> change in pg_proc.h, because the format is easy to parse and has one
>> line per entry. With this new format, that approach would no longer
>> work, and I don't know what would replace it.
> The idea in my mind is that you'd write a Perl program to do such
> changes, yeah. If the code we supply contains enough helpers and a few
> samples, it should be reasonably simple for people that don't do much
> Perl.
It would be good to see a sample --- for a concrete example, how about
creating a Perl script to do the conversion Peter mentions?
>>> 3. references to objects in other catalogs are by name, such as "int8"
>>> or "btree/integer_ops" rather than OID.
>> I think we could already do this by making more use of things like
>> regtype and regproc. That should be an easy change to make.
> Well, that assumes we *like* the current format, which I think is not a
> given ... more the opposite.
Note that we *can't* easily improve that given the current tooling,
mainly because the bootstrap-time capabilities of regproc_in et al are
so limited. We don't even have regxxx types for many of the other
cross-reference columns like opclass references, and I don't think
I want to build them because they'd also have bootstrapping issues.
According to my understanding, part of what's going on here is that
we're going to teach genbki.pl to parse these object references and
convert them to hard-coded OIDs in the emitted BKI file. That seems
good to me, but one thing we're going to need is a spec for how
genbki.pl knows what to do.
>> I'm afraid a key value system would invite writing the attributes in
>> random order and create a mess over time.
> Yeah, I share this concern. But you could fix it if the Perl tooling to
> write these files had a hardcoded list to work with. Maybe we could put
> it in a declaration of sorts at the start of each data file.
This is more or less the same concern I stated upthread. But the
impression I'm getting is that we expect these files to often be written
out from a Perl script, so it's mostly a question of how we teach the
Perl scripts to emit stylistically consistent data. Then we can use the
Perl scripts as a kind of pgindent for this data.
>> But if we want to do it, I think we could also add it to the current BKI
>> format. The same goes for defining default values for some columns.
> As above -- do we really like our current format so much that we're
> satisfied with minor tweaks?
I'm sure not. This will be a big change, without a doubt, but I think
we'll end up in a better place.
regards, tom lane