Re: merging some features from plpgsql2 project

2017-01-09 0:37 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 1/8/17 2:52 AM, Joel Jacobson wrote:
>
>> And please kill all these GUCs ideas. The best thing with PostgreSQL
>> is the natural expected behaviour of the default configuration.
>> Contrary to MySQL where you have to enable lots and lots of
>> configuration options just to get a behaviour you expect as a novice
>> user.
>>
>
> The only reason to use GUCs or some other kind of backwards compatibility
> setting would be to allow the current plpgsql itself to move forwards. If
> you think that's a dead end (which I can certainly understand) then they
> make no sense at all.
>
> It's much better to just come together and agree on whatever we have
>> learned during the last 15 years of PL/pgSQL1, and sample all ideas
>> during a year maybe, and decide what to put into PL/pgSQL2. To make it
>> useful, we should aim to not break compatibility for _most_ code, but
>> accept some necessary rewrites of functions with deprecated
>> anti-patterns.
>>
>
> If we're going to create a brand new language then I think it would be
> extremely foolish to keep *any* of the current pain points around. Off the
> top of my head:
>
> - variables must have an identifier (what $ in most languages does). The
> steps you have to go through to avoid simple naming collisions are insane.
>

just note - from 9.0 the collisions are not a issue

>
> - Support for composite types needs to be stronger. Off the top of my
> head, you need to be able to reference an element name via a variable. OR,
> maybe it'd be better to just provide a plpgsql equivalent to a dict.
>

This point self needs significant code refactoring - maybe total rewriting
PL executor - it allows to change expression result data type in cycle. It
doesn't mean so I fully disagree with this point, but it is not easy to
implement it in type strict environment - C, C++, Pascal, Ada - hasn't any
similar - maybe it is possible with some libraries.

>
> - GET DIAGNOSTICS and their ilk need to die. There needs to be an easier
> way to get that kind of info back (perhaps via an automatic
> composite/record/dict).
>

It is about performance - probably you wouldn't to fill all dict fields
after any statement.

>
> - There needs to be real support for dealing with exceptions. IE: get a
> composite of all exception deatils, modify parts of it, then re-raise with
> the new info.
>
> - Real support for using variables as identifiers / nothing restricted to
> only accepting a Const.
>

second point that enforces new PL environment - writing from scratch - and
it hides the cost of dynamic SQL

>
> - Support for the notion of a variable being unset (which is NOT the same
> thing as NULL).
>
>
> That said, I'll bet we still get some of that wrong, so there better be
> some way of fixing those issues down the road...

With these requests you have to specify first, how much close will be your
ideal language with PostgreSQL. Currently PL/pgSQL is pretty close - with
some impacts. Your mentioned features can requires more independent
environment from Postgres.

What is really weak in plpgsql is a left side of assign statement and
missing some global/module/extensions variables.

Maybe if we integrate more PLLua or PLPython, PLPerl it can be better for
these requests.

I am not sure about benefit new only PostgreSQL specific language. What do
you think about Lua - it is light, pretty fast, dynamic, fast dictionary
API that can mask lot of internals.

Regards

Pavel

>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532)
>