Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs
Date: 2020-11-26 07:48:48
Message-ID: CAFj8pRBXcqftkfXyQ9sjHP2uBtyca_V+Oak_3o8gtpVYeSk4Lw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> napsal:

> Hackers,
>
> Bug # 16519 [1] is another report of confusion regarding trying to use
> parameters in improper locations - specifically the SET ROLE command within
> pl/pgsql. I'm re-attaching the doc patch and am adding it to the
> commitfest.
>

I checked this patch, and I think so it is correct - my comments are just
about enhancing by some examples

Maybe for following sentence the some examples can be practical

+ If the SQL command being executed is incapable of returning a result
+ it does not accept query parameters.
</para>

+ it does not accept query parameters (usually DDL commands like CREATE
TABLE, DROP TABLE, ALTER ... ).

+ Query parameters will only be substituted in places where
syntactically allowed
+ (in particular, identifiers can never be replaced with a query
parameter.)
+ As an extreme case, consider this example of poor programming style:

In this case, I miss the more precious specification of identifiers

+ (in particular, SQL identifiers (like schema, table, column names) can
never be replaced with a query parameter.)

Regards

Pavel

> David J.
>
> [1]
> https://www.postgresql.org/message-id/16519-9ef04828d058a319%40postgresql.org
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message osumi.takamichi@fujitsu.com 2020-11-26 07:51:32 RE: Stronger safeguard for archive recovery not to miss data
Previous Message Sergei Kornilov 2020-11-26 07:43:50 Re: Stronger safeguard for archive recovery not to miss data