Re: Bootstrap DATA is a pita

The current semantic level is pretty low level, somewhat cumbersome, and
requires filling in values that most of the time the system has a pretty
good idea how to fill in default values.

Compare:

CREATE FUNCTION lo_export(oid, text) RETURNS integer LANGUAGE internal
STRICT AS 'lo_export' WITH (OID=765);
DATA(insert OID = 765 ( lo_export PGNSP PGUID 12 1 0 0 0 f f f f t f v u
2 0 23 "26 25" _null_ _null_ _null_ _null_ _null_ lo_export _null_ _null_
_null_ ));

In the first one someone has indicated:
1. a function name,
2. two parameter type names
3. a return type
4. a language
5. null handling
6. a symbol
7. an oid

In the second case 30 separate items have been indicated, and yet both of
them will generate identical end results within the catalog.

The former is more immune to even needing modification in the event that
the catalog structure changes.
- adding proleakproof? No change needed, default value is correct
- adding protransform? No change needed, not relevant
- adding proparallel? No change needed, default value is correct
- adding procost? No change needed, default value is correct

On Fri, Dec 11, 2015 at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Crazy idea: we could just have a CSV file which can be loaded into a
> > table for mass changes using regular DDL commands, then dumped back from
> > there into the file. We already know how to do these things, using
> > \copy etc. Since CSV uses one line per entry, there would be no merge
> > problems either (or rather: all merge problems would become conflicts,
> > which is what we want.)
>
> That's an interesting proposal. It would mean that the catalog files
> stay at more or less their current semantic level (direct representations
> of bootstrap catalog contents), but it does sound like a more attractive
> way to perform complex edits than writing Emacs macros ;-).
>
> You could actually do that the hard way right now, with a bit of script
> to convert between DATA lines and CSV format. But if we anticipate that
> becoming the standard approach, it would definitely make sense to migrate
> the master copies into CSV or traditional COPY format, and teach BKI mode
> to read that (or, perhaps, leave bootstrap.c alone and modify the code
> that produces the .bki file).
>
> This is somewhat orthogonal to the question of whether we want to do
> things like converting noncritical operator-class definitions into
> regular CREATE OPERATOR CLASS syntax. There's almost certainly going
> to be some hard core of catalog entries that aren't amenable to that,
> and will still need to be loaded from data files of some sort.
>
> regards, tom lane
>