Re: Schema variables - new implementation for Postgres 15 (typo)

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Schema variables - new implementation for Postgres 15 (typo)
Date: 2023-01-11 09:08:08
Message-ID: 20230111090808.muqpwqce2cw4p5t5@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 10, 2023 at 08:35:16PM +0100, Pavel Stehule wrote:
> út 10. 1. 2023 v 3:20 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com> napsal:
> >
> > Another new behavior I see is the new rowtype_only parameter for
> > LookupVariable. Has this been discussed?
> >
>
> I think so it was discussed about table shadowing
>
> without this filter, I lost the message "missing FROM-clause entry for ..."
>
> -- should fail
> SELECT varx.xxx;
> -ERROR: missing FROM-clause entry for table "varx"
> -LINE 1: SELECT varx.xxx;
> - ^
> +ERROR: type text is not composite
> -- don't allow multi column query
> CREATE TYPE vartesttp AS (a1 int, b1 int, c1 int);
> CREATE VARIABLE v1 AS vartesttp;
> @@ -1421,9 +1419,7 @@
> DROP TYPE ab;
> CREATE VARIABLE myvar AS int;
> SELECT myvar.blabla;
> -ERROR: missing FROM-clause entry for table "myvar"
> -LINE 1: SELECT myvar.blabla;
> - ^
> +ERROR: type integer is not composite
> DROP VARIABLE myvar;
> -- the result of view should be same in parallel mode too
> CREATE VARIABLE v1 AS int;
>
> My original idea was to try to reduce possible conflicts (in old versions
> of this path, a conflict was disallowed). But it is true, so these "new"
> error messages are sensible too, and with eliminating rowtype_only I can
> reduce code.

Ok! Another problem is that the error message as-is is highly unhelpful as
it's not clear at all that the problem is coming from an unsuitable variable.
Maybe change makeParamSessionVariable to use lookup_rowtype_tupdesc_noerror()
and emit a friendlier error message? Something like

variable "X.Y" is of type Z, which is not composite

> I modified the IdentifyVariable function a little bit. With new argument
> noerror I am able to ensure so no error will be raised when this function
> is called just for shadowing detection.

I locally modified IdentifyVariable to emit WARNING reports when noerror is set
to quickly see how it was used and didn't get any regression test error. This
definitely needs to be covered by regression tests. Looking as
session_variables.sql, the session_variables_ambiguity_warning GUC doesn't have
a lot of tests in general.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2023-01-11 09:22:50 Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Previous Message Jelte Fennema 2023-01-11 09:04:56 Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf