2009/10/22 Dimitri Fontaine <dfonta...@hi-media.com>: > Tom Lane <t...@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?
-1 without significant refactoring you will be far to plsql. And you don't solve problem of plpgsql. Minimally plpgsql needs better solution of ambiguous identifiers, and have to have some back compatibility possibility. I am thinking about new language based on SQL/PSM syntax - but I am sure, so I don't use current plpgsql interpret. I thing, so there are some possibilities for simplification - but it should to have some incompatibilities (so I would not to back port it to plpgsql). > > 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. > sorry I don't see it cleaner then just #option CREATE FUNCTION foo() RETURNS int AS $$ #option sqlprecedence DECLARE ... .. This mechanism is available now, and don't need to add some new code. Regards Pavel > Regards, > -- > dim > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
