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

út 10. 1. 2023 v 3:20 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com> napsal:

> Hi,
>
> On Sat, Jan 07, 2023 at 08:09:27AM +0100, Pavel Stehule wrote:
> > >
> > > Hmm, how safe is it for third-party code to access the stored data
> directly
> > > rather than a copy? If it makes extension fragile if they're not
> careful
> > > enough with cache invalidation, or even give them a way to mess up
> with the
> > > data directly, it's probably not a good idea to provide such an API.
> > >
> >
> > ok, I removed it
>
> 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.

> I can see how it can be annoying to get a "variable isn't composite" type
> of
> error when you already know that only a composite object can be used (and
> other
> might work), but it looks really scary to entirely ignore some objects that
> should be found in your search_path just because of their datatype.
>
> And if we ignore something like "a.b" if "a" isn't a variable of composite
> type, why wouldn't we apply the same "just ignore it" rule if it's indeed a
> composite type but doesn't have any "b" field? Your application could also
> start to use different object if your drop a say json variable and create a
> composite variable instead.
>

> It seems to be in contradiction with how the rest of the system works and
> looks
> wrong to me. Note also that LookupVariable can be quite expensive since
> you
> may have to do a lookup for every schema found in the search_path, so the
> sooner it stops the better.
>

I removed this filter

>
> > > > updated patches attached
>
> I forgot to mention it last time but you should bump the copyright year
> for all
> new files added when you'll send a new version of the patchset.
>

fixed

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.

Regards

Pavel