Re: PL/pgSQL 2 - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: PL/pgSQL 2
Date
Msg-id CAASwCXeLm6YfLdA+vk33g_NRK0h_Uh0xzYj3UNXMPWzdFhUeKg@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 2  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
+1

I use underscore for *all* variables and input parameters in all
functions. Making that a requirement in plpgsql2 wouldn't break any of
my code.

On Mon, Sep 1, 2014 at 3:52 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 09/01/2014 05:04 PM, Joel Jacobson wrote:
>> From the top of my head, these are Things I personally would want to see
>> in plpgsql2:
>
> Oh, also, I'd *love* to improve how non-plannable statements with
> PL/PgSQL variable subsitutions behave.
>
> *I* understand why the following is wrong:
>
> DO
> $$
> DECLARE
>      tablename text;
> BEGIN
>     tablename := 'sometable';
>     DROP TABLE tablename;
> END;
> $$;
>
> and produces:
>
> ERROR:  table "tablename" does not exist
> CONTEXT:  SQL statement "DROP TABLE tablename"
> PL/pgSQL function inline_code_block line 6 at SQL statement
>
>
> but going by the number of questions I see about this, and similar
> issues with ALTER USER and so on, it's not obvious to new users.
>
> It's not clear how to make this friendly without making it dangerous
> though. If you have:
>
>     DROP TABLE x;
>
> then someone declares a variable
>
>     x := 'customers';
>
> you don't want to suddenly be issuing a
>
>     DROP TABLE customers;
>
> ... which is why I suspect this might need to be not 100% backward
> compatible, perhaps requiring a variable-marker prefix.
>
> --
>  Craig Ringer                   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: PL/pgSQL 2
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL 2