Re: merging some features from plpgsql2 project

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.

- 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.

- 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).

- 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.

- 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...
--
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)