Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 87y6n37nq0.fsf@hi-media-techno.com
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Controlling changes in plpgsql variable resolution  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Controlling changes in plpgsql variable resolution  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> be seen as one.)  And the Oracle-compatible option will be attractive
> to people coming in from that side.  Reviewing megabytes of pl/sql
> code for this kind of gotcha is not fun, and the "error" default would
> only help a bit.

What about having a new pl language called plsql (or mabe plosql) where
it behaves like Oracle. The handler could maybe set the environment then
call the plpgsql interpreter. Is it technically sound?

If it is, it's just another way to spell this unfriendly #option syntax
that people do not like. Yet another idea would be to keep the #option
mecanism but spell it differently, in a more plpgsql like way:
 create funcion ... language plpgsql as $$ OPTIONS  lexer_priority = 'table, variable'; DECLARE  v_foo integer; BEGIN
END;$$;
 

I know I don't like #option because it looks and feels "foreign", so t
might just boils down to syntax issue for others too.

Regards,
-- 
dim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Using views for row-level access control is leaky
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution