Re: PL/pgSQL 2

From: Joel Jacobson <joel(at)trustly(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 2
Date: 2014-09-01 14:34:50
Message-ID: CAASwCXeLm6YfLdA+vk33g_NRK0h_Uh0xzYj3UNXMPWzdFhUeKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-01 14:35:48 Re: PL/pgSQL 2
Previous Message Joel Jacobson 2014-09-01 14:29:18 Re: PL/pgSQL 2