Adrien Nayrat writes:
> I see. So I understand we were lucky it worked before the commit added
> the check of volatility in generated column ?
Pretty much. There are other cases that could trigger expansion
of such a function before the restore is complete. It is unfortunate
that this bit you
On 9/25/24 4:41 PM, Tom Lane wrote:
Adrien Nayrat writes:
A customer encountered an issue while restoring a dump of its database
after applying 15.6 minor version.
It seems due to this fix :
Fix function volatility checking for GENERATED and DEFAULT
expressions (Tom Lane)
I don't believe thi
Adrien Nayrat writes:
> A customer encountered an issue while restoring a dump of its database
> after applying 15.6 minor version.
> It seems due to this fix :
>>> Fix function volatility checking for GENERATED and DEFAULT
>>> expressions (Tom Lane)
I don't believe this example has anything to
Hello,
A customer encountered an issue while restoring a dump of its database
after applying 15.6 minor version.
It seems due to this fix :
> Fix function volatility checking for GENERATED and DEFAULT
expressions (Tom Lane)
> These places could fail to detect insertion of a volatile function
Aleksander Alekseev writes:
>> True, but from the perspective of the affected code, the question is
>> basically "did you call expression_planner() yet". So I like this
>> naming for that connection, whereas something based on "transformation"
>> doesn't really connect to anything in existing fun
Hi,
> True, but from the perspective of the affected code, the question is
> basically "did you call expression_planner() yet". So I like this
> naming for that connection, whereas something based on "transformation"
> doesn't really connect to anything in existing function names.
Fair enough.
Aleksander Alekseev writes:
>>> Oh no! We encountered one of the most difficult problems in computer
>>> science [1].
>> Indeed :-(. Looking at it again this morning, I'm thinking of
>> using "contain_mutable_functions_after_planning" --- what do you
>> think of that?
> It's better but creates
Hi,
> > Oh no! We encountered one of the most difficult problems in computer
> > science [1].
>
> Indeed :-(. Looking at it again this morning, I'm thinking of
> using "contain_mutable_functions_after_planning" --- what do you
> think of that?
It's better but creates an impression that the actua
Aleksander Alekseev writes:
>> There are a couple of points worth bikeshedding perhaps. I didn't
>> spend much thought on the wrapper functions' names, but it's surely
>> true that the semantic difference between contain_mutable_functions
>> and ContainMutableFunctions is quite un-apparent from t
Hi,
I noticed that the patchset needs a review and decided to take a look.
> There are a couple of points worth bikeshedding perhaps. I didn't
> spend much thought on the wrapper functions' names, but it's surely
> true that the semantic difference between contain_mutable_functions
> and Contain
I wrote:
> After digging around, I could only find one other place where
> outside-the-planner code was doing this wrong: AddRelationNewConstraints
> can come to the wrong conclusion about whether it's safe to use
> missingMode. So here's a patch series to resolve this.
Argh ... I forgot to menti
[ moving to pgsql-hackers ]
I wrote:
> Applying expression_planner() solves the problem because it inlines
> anytextcat(anynonarray,text), resolving that the required cast is
> numeric->text which is immutable. The code for generated expressions
> omits that step and arrives at the less desirable
12 matches
Mail list logo
