2017-01-09 0:37 GMT+01:00 Jim Nasby <jim.na...@bluetreble.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) >
