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
Re: Controlling changes in plpgsql variable resolution |
Список | 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 по дате отправления: