Robert Haas <robertmh...@gmail.com> writes: > On Thu, May 4, 2017 at 6:05 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers