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