Re: WIP: a way forward on bootstrap data
John Naylor <jcnaylor@gmail.com>
From: John Naylor <jcnaylor@gmail.com>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-28T11:25:35Z
Lists: pgsql-hackers
Attachments
- 0001-Clarify-special-case-bootstrap-values.patch (text/x-patch) patch 0001
On 4/26/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (The prosrc-from-proname case, in isolation, could be handled about
> as well by adding a hardwired rule like we have for pronargs.)
If we think we might go in the direction of more special-case
behavior, the attached patch more fully documents what we already do,
and does some minor refactoring to make future additions more
straightforward. I think this would even be good to do for v11.
> Robert Haas <robertmhaas@gmail.com> writes:
>> -1 for trying to automate this. It varies between fooin and foo_in,
>> and it'll be annoying to have to remember which one happens
>> automatically and which one needs an override.
>
> Yeah, that was my first reaction to that example as well. If it
> weren't so nearly fifty-fifty then we might have more traction there;
> but it's pretty close, and actually the foo_in cases outnumber fooin
> if I counted correctly. (Array entries should be ignored for this
> purpose; maybe we'll autogenerate them someday.)
Hmm, that wouldn't be too hard. Add a new metadata field called
'array_type_oid', then if it finds such an OID, teach genbki.pl to
construct a tuple for the corresponding array type by consulting
something like
char typcategory BKI_ARRAY(A);
char typstorage BKI_ARRAY(x);
...etc
in the header file, plus copying typalign from the element type. I'll
whip this up sometime and add it to the next commitfest.
On 4/26/18, Mark Dilger <hornschnorter@gmail.com> wrote:
> /* cast method */
> - char castmethod;
> + char castmethod BKI_DEFAULT("/${castfunc} == 0 ? 'b' : 'f'/e");
> } FormData_pg_cast;
I don't have a strong opinion about your simple substitution
mechanism, but I find the above a bit harder to reason about. It also
has the added disadvantage that there is whitespace in the BKI
annotation, so it can no longer be parsed with the current setup. That
could be overcome with additional complexity, of course, but then
you're back in the position of advocating that for a single use case.
-John Naylor
Commits
-
Clarify handling of special-case values in bootstrap catalog data.
- 45c6d75f8cd2 11.0 landed
-
Replace our traditional initial-catalog-data format with a better design.
- 372728b0d495 11.0 landed
-
Faster partition pruning
- 9fdb675fc5d2 11.0 cited
-
Minor cleanup in genbki.pl.
- 8d90b4d01a61 11.0 landed
-
Trivial adjustments in preparation for bootstrap data conversion.
- a351679c806e 11.0 landed
-
Remove hard-coded schema knowledge about pg_attribute from genbki.pl
- 49c784ece766 11.0 landed
-
Minor edits to catalog files and scripts
- 9373baa0f764 11.0 landed
-
Hide most variable-length fields from Form_pg_* structs
- 8137f2c32322 9.2.0 cited