Re: [HACKERS] merging some features from plpgsql2 project
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] merging some features from plpgsql2 project |
Дата | |
Msg-id | 517894ec-77b3-0c18-b0ee-bdfaf8bb33a5@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] merging some features from plpgsql2 project (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: [HACKERS] merging some features from plpgsql2 project
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] merging some features from plpgsql2 project (Pavel Stehule <pavel.stehule@gmail.com>) Re: [HACKERS] merging some features from plpgsql2 project (Marko Tiikkaja <marko@joh.to>) |
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: