On Tue, Jun 23, 2015 at 2:57 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 6/23/15 9:45 AM, Pavel Stehule wrote: >> 1. parametrized record reference syntax - some like SELECT $1[$] >> 2. possibility to throw plan cache, if result has different type than is >> expected in cache. > > > Well, the other option is we allow for cases where we don't know in advance > what the type will be. That would handle this, JSON, variant, and possibly > some other scenarios. > > BTW, I think this relates to the desire to be able to do more OO-ish things > in the database. Like "do X to all elements in this array". And to have > actual classes, private members, real arrays of arrays. It seems like > there's a bigger need here that's only being addressed piecemeal. :/
I would rephrase that to: "do X to all fields of an object". Array handling is pretty good now (minus arrays of arrays, but arrays of objects containing arrays is 'good enough' for most real world cases). We've suffered for a while now with hstore/json as a temporary container to handle operations that are not well supported by postgres's particularly strongly typed flavor SQL. The "OO" of postgres has been gradually diluting away; it's not a 'object relational' database anymore and the OO features, very much a product of the silly 90's OO hysteria, have been recast into more useful features like inheritance and/or pruned back. I don't mind having to push everything to jsonb and back for tuple manipulation and I expect that's how these types of things are going to be done moving forwards. jsonb has clearly caught a bid judging by what I'm reading in the blogosphere and will continue to accrete features things like this. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers