2015-04-23 15:19 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby <jim.na...@bluetreble.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
