On 6/23/15 3:40 PM, Pavel Stehule wrote:
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 not to open this box - and I would not to throw or redesign almost all PostgreSQL type handling system. I am sure, so it is not necessary. PL can be relative static if the dynamic is covered by query language. The few features can implemented without to necessity to redesign all. Still there are other PL - and we have not force to design new Perl, JavaScript, ...
By that argument why are we putting it into plpgsql either? You can easily do the stuff we've been talking about in plperl (and presumably most other pl's). So why mess around with adding it to plpgsql?
More importantly, these are things that would be extremely useful at the SQL level. When it comes to records for example, we frequently know exactly what's in them, so why do we force users to statically specify that at the SQL level? This is why we don't support pivot tables (which in the BI world is a Big Deal).
I think it's a mistake to try and solve this strictly through plpgsql without recognizing the larger desire and trying to move the ball that direction. I'm not saying a first effort should boil the ocean, but if we keep piecemealing this without more though we're going to keep getting more warts (like a lot of the gotchas we have with arrays).
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
