Andrew Dunstan <and...@dunslane.net> writes:
> +1. If we come up with an agreed format I will undertake to produce the
> requisite perl script. So let's reopen the debate on the data format. I
> want something that doesn't consume large numbers of lines per entry. If
> we remove defaults in most cases we should be able to fit a set of
> key/value pairs on just a handful of lines.
The other reason for keeping the entries short is to prevent patch
misapplications: you want three or less lines of context to be enough
to uniquely identify which line you're changing. So something with,
say, a bunch of <tag></tag> overhead, with that markup split onto
separate lines, would be a disaster. This may mean that we can't
get too far away from the DATA-line approach :-(.
Or maybe what we need to do is ensure that there's identification info on
every line, something like (from the first entry in pg_proc.h)
boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool
boolin: prosrc=boolin provolatile=i proparallel=s
(I'm imagining the prefix as having no particular semantic significance,
except that identical values on successive lines denote fields for a
single catalog row.)
With this approach, even if you had blocks of boilerplate-y lines
that were the same for many successive functions, the prefixes would
keep them looking unique to "patch".
On the other hand, Andrew might be right that with reasonable defaults
available, the entries would mostly be short enough that there wouldn't
be much of a problem anyway. This example certainly looks that way.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
