Re: Allow SQL/plpgsql functions to accept record

2015-04-23 15:19 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
> wrote:
> > On 4/22/15 2:12 PM, Merlin Moncure wrote:
> >> That being said, I think json types with their associated API, given
> >> that they are core types, will ultimately handle these types of
> >> problems. That way, at least, we can avoid adding syntax and
> >> functionality that will basically do the same thing. This reminds me
> >> a little bit of the json_build() vs enhanced row() syntax we discussed
> >> some time back. I didn't say so at the time, but for posterity, I
> >> think you were right...json_build() is working fine for building
> >> arbitrary record types and moving a record to json and deconstructing
> >> it should work just as well.
> >
> > The one part I don't care for in that is it seems rather inefficient to
> cast
> > something to JSON just so we can do things we really should be able to do
> > with a record. But perhaps it's not all that costly.
> >
> > As for allowing SQL and plpgsql functions to accept a record, I think our
> > JSON functionality just provided plenty of reason we should allow
> accepting
> > them, even if you can't do much with it: you *can* hand it to
> row_to_json(),
> > which does allow you to do something useful with it. So it seems
> reasonable
> > to me that we should at least accept it as a function argument.
>
> 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.

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>