From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) |
Cc: | John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generating bootstrap entries for array types |
Date: | 2018-09-20 19:17:57 |
Message-ID: | 2120.1537471077@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I'm inclined to think the right way is to do the expansion always,
>> and teach reformat_dat_file.pl to drop autogenerated array types
>> on the way out, making this work more like the existing facilities
>> for default/computed fields.
>>
>> The easiest way to make that happen seems to be to invent another, purely
>> internal metadata field, along the lines of "is_autogenerated_entry".
>> Fooling with that now ...
> Something like this, on top of the v2 patch?
Yeah, that's pretty close to what I came up with, except that I thought
it'd be good if "reformat_dat_file.pl --full-tuples" would print
autogenerated entries; seems useful for debug purposes if nothing else.
So that requires also teaching ParseData to ignore autogenerated entries
on read-in, else you end up with duplicates.
I did some other minor hacking (mostly, fixing the documentation)
and pushed it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-20 19:30:05 | Re: generating bootstrap entries for array types |
Previous Message | John Naylor | 2018-09-20 18:30:18 | Re: generating bootstrap entries for array types |