On 4/23/15 8:33 AM, Pavel Stehule wrote:
I agree that that would be useful. I think the problem with an
expression like rowvar.something is that PL/pgsql cannot infer the
type of the result, and nothing else works without that. I doubt that
it's practical to lift that restriction. PL/pgsql could introduce
dedicated syntax for this operation, like DYNAMIC_EXTRACT(rowvar,
colname, resulttype) or something, but that's going to be clunky at
best. Whether we eventually do that or not, if we can allow rows to
be passed in and then let people use json or hstore operators on them,
that would be a helpful step forward, IMHO. I'm not sure if that's
practical either, but maybe...
this need significant changes in plpgsql - it can enforce work with
different types in expressions in cycle - so we should to leave
expressions based on plans or we have to introduce alternated plans for
different input types.
Is this fundamentally an issue of not knowing what we're being handed
when we compile the function? Perhaps a way around this limitation would
be to recompile during execution if any record arguments get a different
base type. In reality, I suspect that won't happen during a single query.
I'll take a look at at least allowing passing a record in so you can
hand it to some other function. Any pointers on how to do that would be
welcome; I've never hacked on plpgsql or SQL function code before.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers