Re: Schema variables - new implementation for Postgres 15 (typo)
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Erik Rijkers <er@xs4all.nl>, Sergey Shinderuk <s.shinderuk@postgrespro.ru>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, dean.a.rasheed@gmail.com, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2023-01-16T20:27:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow underscores in integer and numeric constants.
- faff8f8e47f1 16.0 cited
-
Remove special outfuncs/readfuncs handling of RangeVar.catalogname.
- 3cece34be842 16.0 cited
-
Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
- 2af33369e794 16.0 cited
-
Create FKs properly when attaching table as partition
- b0284bfb1db5 16.0 cited
-
psql: improve tab-complete's handling of variant SQL names.
- 02b8048ba5dc 15.0 cited
Attachments
- v20230116-1-0010-documentation.patch (text/x-patch) patch v20230116-0010
- v20230116-1-0009-this-patch-changes-error-message-column-doesn-t-exis.patch (text/x-patch) patch v20230116-0009
- v20230116-1-0006-enhancing-psql-for-session-variables.patch (text/x-patch) patch v20230116-0006
- v20230116-1-0007-possibility-to-dump-session-variables-by-pg_dump.patch (text/x-patch) patch v20230116-0007
- v20230116-1-0008-regress-tests-for-session-variables.patch (text/x-patch) patch v20230116-0008
- v20230116-1-0005-DISCARD-VARIABLES-command.patch (text/x-patch) patch v20230116-0005
- v20230116-1-0004-support-of-LET-command-in-PLpgSQL.patch (text/x-patch) patch v20230116-0004
- v20230116-1-0003-LET-command.patch (text/x-patch) patch v20230116-0003
- v20230116-1-0002-session-variables.patch (text/x-patch) patch v20230116-0002
- v20230116-1-0001-catalog-support-for-session-variables.patch (text/x-patch) patch v20230116-0001
st 11. 1. 2023 v 10:08 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal: > 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@gmail.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 > done > > > 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. > I enhanced regress tests about this scenario Regards Pavel