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