Re: Allow SQL/plpgsql functions to accept record

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