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