On 11/13/2016 11:11 AM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
I'm not convinced the line prefix part is necessary, though. What I'm
thinking of is something like this:
PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1
rettype=bool argtypes="cstring" src=boolin );
We could go in that direction too, but the apparent flexibility to split
entries into multiple lines is an illusion, at least if you try to go
beyond a few lines; you'd end up with duplicated line sequences in
different entries and thus ambiguity for patch(1). I don't have any
big objection to the above, but it's not obviously better either.
Yeah, I looked and there are too many cases where the name would be
outside the normal 3 lines of context.
Some things we should try to resolve before settling definitively on
a data representation:
1. Are we going to try to keep these things in the .h files, or split
them out? I'd like to get them out, as that eliminates both the need
to keep the things looking like macro calls, and the need for the data
within the macro call to be at least minimally parsable as C.
That would work fine for pg_proc.h, less so for pg_type.h where we have
a whole lot of
#define FOOOID nn
directives in among the data lines. Moving these somewhere remote from
the catalog lines they relate to seems like quite a bad idea.
2. Andrew's example above implies some sort of mapping between the
keywords and the actual column names (or at least column positions).
Where and how is that specified?
There are several possibilities. The one I was leaning towards was to
parse out the Anum_pg_foo_* definitions.
3. Also where are we going to provide the per-column default values?
How does the converter script know which columns to convert to type oids,
proc oids, etc? Is it going to do any data validation beyond that, and
if so on what basis?
a) something like DATA_DEFAULTS( foo=bar );
b) something like DATA_TYPECONV ( rettype argtypes allargtypes );
Hadn't thought about procoids, but something similar.
4. What will we do about the #define's that some of the .h files provide
for (some of) their object OIDs? I assume that we want to move in the
direction of autogenerating those macros a la fmgroids.h, but this needs
a concrete spec as well. If we don't want this change to result in a big
hit to the source code, we're probably going to need to be able to specify
the macro names to generate in the data files.
Yeah, as I noted above it's a bit messy,
5. One of the requirements that was mentioned in previous discussions
was to make it easier to add new columns to catalogs. This format
does that only to the extent that you don't have to touch entries that
can use the default value for such a column. Is that good enough, and
if not, what might we be able to do to make it better?
I think it is good enough, at least for a first cut.
I'd actually like to roll up the DESCR lines in pg_proc.h into this too,
they strike me as a bit of a wart. But I'm flexible on that.
+1, if we can come up with a better syntax. This together with the
OID-macro issue suggests that there will be items in each data entry that
correspond to something other than columns of the target catalog. But
that seems fine.
If we can generalize this to other catalogs, then that will be good, but
my inclination is to handle the elephant in the room (pg_proc.h) and
worry about the gnats later.
I think we want to do them all. pg_proc.h is actually one of the easier
catalogs to work on presently, IMO, because the only kind of
cross-references it has are type OIDs. Things like pg_amop are a mess.
And I really don't want to be dealing with multiple notations for catalog
data. Also I think this will be subject to Polya's paradox: designing a
general solution will be easier and cleaner than a hack that works only
for one catalog.
I don't know that we need to handle everything at once, as long as the
solution is sufficiently general.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: