Re: proposal: plpgsql pragma statement

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql pragma statement
Date: 2019-03-07 16:45:53
Message-ID: CAFj8pRBRwDmfadvwYmbPU2M9i0sd1VGtGVZLLc6PbGpv2s9OZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 7. 3. 2019 v 14:40 odesílatel Andrew Dunstan <
andrew(dot)dunstan(at)2ndquadrant(dot)com> napsal:

>
> On 3/7/19 3:19 AM, Pavel Stehule wrote:
> > Hi
> >
> > čt 7. 3. 2019 v 8:03 odesílatel David Steele <david(at)pgmasters(dot)net
> > <mailto:david(at)pgmasters(dot)net>> napsal:
> >
> > On 2/4/19 8:12 PM, Pavel Stehule wrote:
> > >
> > > attached rebased patch
> >
> > This patch has gone through a few iterations but I don't think
> > there's
> > any agreement on what it should look like. There's been no code
> > review
> > that I can see.
> >
> > I think this should be pushed to PG13 at the least, perhaps returned
> > with comment or rejected.
> >
> >
> > This patch is in this moment in this form interesting just for
> > plpgsql_check's users.
> >
> > I cannot to move forward without this functionality .. I have a
> > promise of review by some people from big company that uses
> > plpgsql_check, but if there is not interest from commiter's side, then
> > it is not time for pushing this patch today.
> >
> > On second hand, the proposed syntax is same like for autonomous
> > transactions, so I believe, so this patch will come in few years.
> >
> > Please, wait few week, and then it can be rejected.
> >
> >
>
>
> I have looked at the latest patch, but it seems inadequate unless I'm
> misreading it. I think a general pragma mechanism should allow a pragma
> just about anywhere. If the processor doesn't recognize the pragma it
> ignores it, if it does it processes it in the appropriate context. That
> could be for the next statement, the current block, or whatever. If it
> appears in the wrong context the processor should object.
>
>
> For example, one of Ada's predefined pragmas is PAGE, which causes a
> processor producing a program listing to emit a page feed. (Yes, I know,
> probably silly, but you get the idea why this pragma can accur just
> about anywhere.) There is also 'pragma Assert' which is more or less
> like our Assert in C.
>
>
a PRAGMA can be used on three levels (related to Postgres): function,
block, line (and on package on Ada and PLpgSQL). Any PRAGMA has a scope
related to usage.

My first patch implemented all levels, but If I understand it well, Tom has
strong disagreement with line's level.

So I reduced it just for block level - it is good enough for plpgsql_check,
and it is good enough for future autonomous transactions. Other levels can
be very simply supported, but I don't need it, and in this moment, I had
not a case for it.

For plpgsql_check I need to read some non code informations like: disable,
enable some checks, assign some type to record variable, assign some
informations about dynamic SQL, ... I think so PRAGMA is very natural tool
for this purpose.

My implementation of PRAGMA in this moment just push some tag and some
information to AST. It ensure correct syntax. It doesn't do more. But it is
good enough for plpgsql_check.

Regards

Pavel

>
> cheers
>
>
> andrew
>
>
> --
> Andrew Dunstan https://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-03-07 16:48:32 Re: PostgreSQL vs SQL/XML Standards
Previous Message Robert Haas 2019-03-07 15:49:29 Re: [PROPOSAL] Drop orphan temp tables in single-mode