Re: Controlling changes in plpgsql variable resolution

2009/10/22 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>