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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
