Re: PL/pgSQL 2
От | Hannu Krosing |
---|---|
Тема | Re: PL/pgSQL 2 |
Дата | |
Msg-id | 54044B3C.9070308@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: PL/pgSQL 2 (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: PL/pgSQL 2
|
Список | pgsql-hackers |
On 09/01/2014 12:00 PM, Marko Tiikkaja wrote: > On 9/1/14 11:53 AM, Hannu Krosing wrote: >> On 09/01/2014 11:24 AM, Andres Freund wrote: >>> Look at the *disaster* the few minor changes in python3 were. It's now, >>> years after, only starting to get used again. >>> >>> You're going to have to find a more gradual way of doing this. >> Probably a better way (and there has been some talk of it) is >> having some kind of PRAGMA functionality, or pl/pgsql specific >> LOCAL SET to affect "just this function" and not spill to nested >> functions as is the case for SETs now. > > I can't imagine how that would work for anyone who has thousands of > functions. > > I've tried my best over the past ~year or so, but any attempts at > breaking backwards compatibility have been rejected. I really don't > see any gradual way of doing this. We either break things, live with > what we have right now, or create a new language. > > > .marko My approach would be to add optional LOCAL modifier to WITH, so instead CREATE [ OR REPLACE ] FUNCTION name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = } default_expr ] [, ...] ] ) ... [ WITH ( attribute [, ...] ) ] it would be ... [ WITH ( [LOCAL] attribute [, ...] ) ] where LOCAL attributes are _not_ inherited by nested functions but the LOCALs would shadow globals in the function definitions that have them. I know it is easier said than done, but from the user perspective this could be a nice clean approach. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
В списке pgsql-hackers по дате отправления: