From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bootstrap DATA is a pita |
Date: | 2015-02-21 16:34:09 |
Message-ID: | 32726.1424536449@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2015-02-20 22:19:54 -0500, Peter Eisentraut wrote:
>> On 2/20/15 8:46 PM, Josh Berkus wrote:
>>> Or what about just doing CSV?
>> I don't think that would actually address the problems. It would just
>> be the same format as now with different delimiters.
> Yea, we need hierarchies and named keys.
Yeah. One thought though is that I don't think we need the "data" layer
in your proposal; that is, I'd flatten the representation to something
more like
{
oid => 2249,
oiddefine => 'CSTRINGOID',
typname => 'cstring',
typlen => -2,
typbyval => 1,
...
}
This will be easier to edit, either manually or programmatically I think.
The code that turns it into a .bki file will need to know the exact set
of columns in each system catalog, but it would have had to know that
anyway I believe, if you're expecting it to insert default values.
Ideally the column defaults could come from BKI_ macros in the catalog/*.h
files; it would be good if we could keep those files as the One Source of
Truth for catalog schema info, even as we split out the initial data.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-02-21 16:43:09 | Re: Bootstrap DATA is a pita |
Previous Message | Andres Freund | 2015-02-21 16:30:24 | Re: deparsing utility commands |