Re: Controlling changes in plpgsql variable resolution - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id 87y6n37nq0.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Controlling changes in plpgsql variable resolution
Re: Controlling changes in plpgsql variable resolution
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Using views for row-level access control is leaky
Next
From: Pavel Stehule
Date:
Subject: Re: Controlling changes in plpgsql variable resolution