Re: Rethinking plpgsql's assignment implementation

Chapman Flack <chap@anastigmatix.net> writes:
> On 12/11/20 12:21, Tom Lane wrote:
>> solution I adopted was just to invent a new CoercionContext value
>> COERCION_PLPGSQL, representing "use pl/pgsql's rules".  (Basically
>> what that means nowadays is to apply CoerceViaIO if assignment cast
>> lookup doesn't find a cast pathway.)

> That seems like a rule that might be of use in other PLs or extensions;
> could it have a more generic name, COERCION_FALLBACK or something?

I'm not wedded to that name, but I doubt that it's semantics that we
really want to encourage anyone else to use.  In particular, the fact
that it's not a superset of COERCION_EXPLICIT is pretty darn weird,
with little except backwards compatibility to recommend it.

>> is now quoted, but the "SET n:" bit in front of it might confuse people,
>> especially if we don't document this new syntax (which I'm inclined not
>> to, since it's useless in straight SQL).

> If it's true that the only choices for n: are 1: or 2:, maybe it would look
> less confusing in an error message to, hmm, decree that this specialized SET
> form /always/ takes a two-component name, but accept something special like
> ROUTINE.x (or UNNAMED.x or NULL.x or something) for the case where there
> isn't a qualifying label in the plpgsql source?

As the patch stands, it's still using the RECFIELD code paths, which
means that there could be three-component target variable names
(label.variable.field).  If we were to get rid of that and expect
top-level field assignment to also be handled by this new mechanism,
then maybe your idea could be made to work.  But I have not tried to
implement that here, as I don't see how to make it work for RECORD-type
variables (where the names and types of the fields aren't determinate).

In any case, that approach still involves inserting some query text
that the user didn't write, so I'm not sure how much confusion it'd
remove.  The "SET n:" business at least looks like it's some weird
prefix comparable to "LINE n:", so while people wouldn't understand
it I think they'd easily see it as something the system prefixed
to their query.

Looking a bit ahead, it's not too hard to imagine plpgsql wishing
to pass other sorts of annotations through SPI and down to the core
parser.  Maybe we should think about a more general way to do that
in an out-of-band, not-visible-in-the-query-text fashion.

			regards, tom lane