Robert Haas <> writes:
> On Thu, May 4, 2017 at 6:05 PM, Tom Lane <> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to