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

út 10. 1. 2023 v 3:20 odesílatel Julien Rouhaud <rjuju123@gmail.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