Re: [HACKERS] merging some features from plpgsql2 project - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: [HACKERS] merging some features from plpgsql2 project |
| Date | |
| Msg-id | CAFj8pRDJVQ1dE1KO-q1kub-ZOL-xtYBC5thOFMrL4bQOrYmx-w@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] merging some features from plpgsql2 project (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| List | pgsql-hackers |
2017-01-09 0:37 GMT+01:00 Jim Nasby <Jim.Nasby@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)
pgsql-hackers by date: