Re: [HACKERS] what's up with IDENTIFIER_LOOKUP_EXPR?

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 4, 2017 at 6:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> PLpgSQL_datum is really a symbol table entry.  The conflict against what
>> we mean by "Datum" elsewhere is pretty unfortunate.

> Yeah.  That's particularly bad because datum is a somewhat vague word
> under the best of circumstances (like "thing").  Maybe I'm missing
> something, but isn't it more like a parse tree than a symbol table
> entry?  The symbol table entries seem to be based on
> PLpgSQL_nsitem_type, not PLpgSQL_datum, and they only come in the
> flavors you'd expect to find in a symbol table: label, var, row, rec.

Right, there's this separate name lookup table that maps from names to
PLpgSQL_datums.  I personally wouldn't call the PLpgSQL_datum items
parse trees, since they're mostly pretty flat.  But if you want to
think of them that way I can't stop you.

One other important, and unfortunate, thing is that the PLpgSQL_datums
aren't (usually) read-only --- they not only hold static symbol-table-like
info but also the actual current values, for those datums that correspond
directly to a stored variable value (VAR and REC, but not ROW or RECFIELD
or ARRAYELEM).  This seems messy to me, and it forces a rather expensive
copy step during plpgsql function startup.  I'd like to see those duties
separated, so that the actual r/w state is just arrays of Datum/isnull
that we can trivially initialize during function start.

>> So, this representation is great for speed of access and modification
>> of individual fields of the composite variable.  It sucks when you
>> want to assign to the composite as a whole or retrieve its value as
>> a whole, because you have to deconstruct or reconstruct a tuple to
>> do that.  (The REC/RECFIELD approach has approximately the opposite
>> strengths and weaknesses.)  Also, dealing with changes in the named
>> composite type is a complete fail, because we've built its structure
>> into the function's symbol table at parse time.

> It would probably be possible to come up with a representation that
> allowed both things to be efficient,

Yeah, perhaps.  It would be good to take two steps back and reconsider
the whole data structure.

> I'm not volunteering to do the work, though.

It's not at the top of my priority list either, but I'd like to see it
happen sometime.
        regards, tom lane