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

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

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)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to