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  (Joel Jacobson <joel@trustly.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: ALTER SYSTEM RESET?
Следующее
От: Jeevan Chalke
Дата:
Сообщение: Re: Re: proposal: ignore null fields in not relation type composite type based constructors