Hello
Another example where explicit search path is needed.
CREATE TABLE public.B(b INTEGER);
CREATE TABLE pg_temp.B(b INTEGER);
CREATE OR REPLACE FUNCTION f3 () RETURNS VOID
LANGUAGE sql SECURITY DEFINER
BEGIN ATOMIC
INSERT INTO B(b) VALUES (1);
END;
SELECT f3();
SELECT * FROM public.B;
/*Res
Hello!
I've prepared a patch to add some missing periods and tags.
I also suggest the following change in pgbench.sgml:
- Here is some example output generated with these options:
+ Here is some example output generated with this option:
since I believe that this is the example for the --aggr
On Fri, Oct 7, 2022 at 01:50:14PM +, Erki Eessaar wrote:
> Hello
>
> Another example where explicit search path is needed.
>
> CREATE TABLE public.B(b INTEGER);
> CREATE TABLE pg_temp.B(b INTEGER);
>
> CREATE OR REPLACE FUNCTION f3 () RETURNS VOID
> LANGUAGE sql SECURITY DEFINER
> BEGIN ATO
On Fri, Oct 7, 2022 at 08:05:36AM +, Erki Eessaar wrote:
> Hello
>
> I confirmed, that setting search_path is indeed sometimes needed in case of
> SECURITY DEFINER routines that have SQL-standard bodies. See an example at the
> end of the letter.
>
> I suggest the following paragraph to the
On 2022-Oct-06, PG Doc comments form wrote:
> See the heading: "Table 9.2. Comparison Predicates"
>
> "2 BETWEEN 3 AND 1 → f" # ok this is false.
>
> But let's read the example immediately below (the 'not between' example)
>
> 2 NOT BETWEEN 1 AND 3 → f # what? This is also false. how can the
Hello
I confirmed, that setting search_path is indeed sometimes needed in case of
SECURITY DEFINER routines that have SQL-standard bodies. See an example at the
end of the letter.
I suggest the following paragraph to the documentation:
Starting from PostgreSQL 14 SQL-standard bodies can be use
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/functions.html
Description:
https://www.postgresql.org/docs/14/functions-comparison.html
See the heading: "Table 9.2. Comparison Predicates"
"2 BETWEEN 3 AND 1 → f" # ok this is false.