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
