15.06.2023 17:49, Tom Lane пишет:
"David G. Johnston" writes:
The failure to find and execute the function code itself is not a failure
mode that these markers need be concerned with. Assuming one can execute
the function an immutable function will give the same answer for the same
input for
On Thu, 15 Jun 2023 at 10:49, Tom Lane wrote:
In particular, we've never enforced that an immutable function can't
> call non-immutable functions. While that would seem like a good idea
> in the abstract, we've intentionally not tried to do it. (I'm pretty
> sure there is more than one round of
"David G. Johnston" writes:
> The failure to find and execute the function code itself is not a failure
> mode that these markers need be concerned with. Assuming one can execute
> the function an immutable function will give the same answer for the same
> input for all time.
The viewpoint taken
On 2023-06-15 10:19, David G. Johnston wrote:
The failure to find and execute the function code itself is not a
failure
mode that these markers need be concerned with. Assuming one can
execute
the function an immutable function will give the same answer for the
same
input for all time.
That
On Thursday, June 15, 2023, wrote:
>
> So one could take a strict view that "no PL/Java function should
> ever be marked IMMUTABLE" because every one depends on fetching
> something (once, at least).
>
The failure to find and execute the function code itself is not a failure
mode that these mark
On 2023-06-15 09:58, c...@anastigmatix.net wrote:
also influences what snapshot the
function is looking at, and therefore what it can see, which has
also struck me more as a tacked-on effect than something inherent
in the declaration's meaning.
I just re-read that and realized I should anticipa
c...@anastigmatix.net writes:
> And also, isn't it the case that IMMUTABLE should mark a function,
> not merely that "doesn't manipulate data", but whose return value
> doesn't depend in any way on data (outside its own arguments)?
Right. We can't realistically enforce that either, so it's
up to
15.06.2023 16:58, c...@anastigmatix.net пишет:
On 2023-06-15 09:21, Tom Lane wrote:
Yura Sokolov writes:
not enough to be sure function doesn't manipulate data.
Of course not. It is the user's responsibility to mark functions
properly.
And also, isn't it the case that IMMUTABLE should m
On 2023-06-15 09:21, Tom Lane wrote:
Yura Sokolov writes:
not enough to be sure function doesn't manipulate data.
Of course not. It is the user's responsibility to mark functions
properly.
And also, isn't it the case that IMMUTABLE should mark a function,
not merely that "doesn't manipulat
15.06.2023 16:21, Tom Lane wrote:
Yura Sokolov writes:
I found, than declaration of function as IMMUTABLE/STABLE is not enough to be
sure
function doesn't manipulate data.
Of course not. It is the user's responsibility to mark functions
properly. Trying to enforce that completely is a fool'
Yura Sokolov writes:
> I found, than declaration of function as IMMUTABLE/STABLE is not enough to be
> sure
> function doesn't manipulate data.
Of course not. It is the user's responsibility to mark functions
properly. Trying to enforce that completely is a fool's errand;
you soon get into try
On Thu, 2023-06-15 at 13:22 +0300, Yura Sokolov wrote:
> Good day, hackers.
>
> I found, than declaration of function as IMMUTABLE/STABLE is not enough to be
> sure
> function doesn't manipulate data.
>
> [...]
>
> + errmsg("Damn1! Update were done
>
Sorry, previous message were smashed for some reason.
I'll try to repeat
I found, than declaration of function as IMMUTABLE/STABLE is not enough
to be sure
function doesn't manipulate data.
In fact, SPI checks only direct function kind, but fails to check
indirect call.
Attached immutable_
Good day, hackers.
I found, than declaration of function as IMMUTABLE/STABLE is not enough to be
sure
function doesn't manipulate data.
In fact, SPI checks only direct function kind, but fails to check indirect call.
Attached immutable_not.sql creates 3 functions:
- `immutable_direct` is IMMU
14 matches
Mail list logo
