Re: merging some features from plpgsql2 project

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>
Subject: Re: merging some features from plpgsql2 project
Date: 2017-01-09 09:01:15
Message-ID: CAFj8pRAHg3OXwjH=+u0kgNFVFwF_7PoyuWx6XGhb=UYx1JMkuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-01-09 1:10 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 1/8/17 12:03 AM, Pavel Stehule wrote:
>
>> BTW, I do wish you could change the label of the scope that
>> arguments went into, so that you could use that label to refer
>> to function parameters. If we allowed that it'd perhaps be the
>> best of both worlds: you'd be guaranteed access to all auto
>> variables and parameters, and that access wouldn't need to be
>> tied to the function name (which can be both painful and error
>> prone).
>>
>>
>> We can talk about compiler directive.
>>
>> PRAGMA auto_variables_label(xxxx) -- require function scope only
>>
>>
>> If we know a list of all auto variables, then it can be on function or
>> block level - it can create aliases.
>>
>
> Oh, the problem is that if you have an argument with the same name as an
> auto variable you're in trouble.
>

I didn't well explained my idea

It is similar to your plpgsql scope. You are introducing the convention. I
proposed a explicit specification. The result is similar.

>
> Probably the easiest thing is to have a scope that sits above the scope
> containing the arguments, and then allow the user to rename both scopes if
> so desired. So in effect you'd end up with
>
> <<plpgsql>> -- new scope
> DECLARE
> FOUND;
> etc
> BEGIN
> <<function_name>>
> DECLARE
> argument_1;
> argument_2;
> BEGIN
> -- User supplied block goes here, with optional label
> END;
> END;
>

It is similar to

PRAGMA auto_variables_namespace(plpgsql);
BEGIN
...
END;

Using PRAGMA is more verbose - it is useful for code audit, review - it is
speaking "I will overwrite some auto variables here, and I need special
namespace"

plpgsql_check, maybe plpgsql self can raise warning if these variables are
shadowed and some option/pragma is not used. Maybe current extra check does
it already.

> Alternatively, we could do...
>
> <<function_name>>
> DECLARE
> FOUND;
> etc
> BEGIN
> DECLARE-- User's DECLARE
> argument_1;
> argomuent_2;
> -- User supplied declare code
> BEGIN -- User's BEGIN
> ....
> END
>
> That removes one level of nesting. It's probably better to go with the
> first option though, since it's simpler.
>

You are forgot on function paramaters - somebody can use a function
argument like FOUND, .. So auto variables should to be declared in most
top namespace.

Usually it is invisible for users - one, two more namespaces has zero cost
for compilation and absolute zero impact for evaluation.

>
> In both cases, I'd really like the ability to rename those blocks. #pragma
> would be fine for that.
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532)
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-01-09 09:01:40 Re: Block level parallel vacuum WIP
Previous Message Masahiko Sawada 2017-01-09 08:48:01 Re: Block level parallel vacuum WIP