Re: Bootstrap DATA is a pita

Поиск
Список
Период
Сортировка
От Caleb Welton
Тема Re: Bootstrap DATA is a pita
Дата
Msg-id CAOjayEfkafbcvOJyrRu6XHzLwZcO-QOs49yggQGsqGbfHTfTdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bootstrap DATA is a pita  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bootstrap DATA is a pita  (Mark Dilger <hornschnorter@gmail.com>)
Список pgsql-hackers
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@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Using quicksort for every external sort run
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort for every external sort run