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 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.
> > > 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.
