>
>
>>
>> you cannot do it - with this you introduce strong dependency on nested
>> objects
>>
>
> What does the plpgsql_check do in this area? I checked the README[1], but
> can't find
> anything about it.
>
When you run plpgsql_check with performance warning (disabled by default),
then it does
On Tue, Apr 20, 2021 at 11:32 AM Pavel Stehule
wrote:
>
>
> út 20. 4. 2021 v 5:16 odesílatel Andy Fan
> napsal:
>
>>
>>
>> On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> út 20. 4. 2021 v 4:47 odesílatel Andy Fan
>>> napsal:
>>>
> - a PL/PGSQL function's
út 20. 4. 2021 v 5:16 odesílatel Andy Fan napsal:
>
>
> On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule
> wrote:
>
>>
>>
>> út 20. 4. 2021 v 4:47 odesílatel Andy Fan
>> napsal:
>>
>>>
>>>
>>> > - a PL/PGSQL function's meaning depends on the search path in effect
>>> when it is called, unless it
On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule
wrote:
>
>
> út 20. 4. 2021 v 4:47 odesílatel Andy Fan
> napsal:
>
>>
>>
>> > - a PL/PGSQL function's meaning depends on the search path in effect
>> when it is called, unless it has a SET search_path clause or it fully
>> qualifies all object
út 20. 4. 2021 v 4:47 odesílatel Andy Fan napsal:
>
>
> > - a PL/PGSQL function's meaning depends on the search path in effect
> when it is called, unless it has a SET search_path clause or it fully
> qualifies all object references, so it isn't actually possible in general
> to determine what a
>
> I'm listening to any obvious reason to reject it.
>
> Any obvious reason to reject it because of it would be a lose battle for
sure,
so I would not waste time on it. Or vote up if you think it is possible and
useful.
--
Best Regards
Andy Fan (https://www.aliyun.com/)
> - a PL/PGSQL function's meaning depends on the search path in effect when
it is called, unless it has a SET search_path clause or it fully qualifies
all object references, so it isn't actually possible in general to
determine what a function calls at definition time
I'd think this one as a
On Sun, Apr 18, 2021 at 9:08 AM Tom Lane wrote:
> Isaac Morland writes:
> > On Sun, 18 Apr 2021 at 11:36, Tom Lane wrote:
> >> Are you familiar with the halting problem? I don't see any meaningful
> >> difference here.
>
> > I think what is being suggested is akin to type checking, not
Isaac Morland writes:
> On Sun, 18 Apr 2021 at 11:36, Tom Lane wrote:
>> Are you familiar with the halting problem? I don't see any meaningful
>> difference here.
> I think what is being suggested is akin to type checking, not solving the
> halting problem.
Yeah, on further thought we'd be
On Sun, 18 Apr 2021 at 11:36, Tom Lane wrote:
> Andy Fan writes:
> > We know volatile is very harmful for optimizers and it is the default
> > value (and safest value) if the user doesn't provide that. Asking user
> > to set the value is not a good experience, is it possible to
>
Andy Fan writes:
> We know volatile is very harmful for optimizers and it is the default
> value (and safest value) if the user doesn't provide that. Asking user
> to set the value is not a good experience, is it possible to auto-generate
> the value for it rather than use the volatile directly
ne 18. 4. 2021 v 17:06 odesílatel Andy Fan
napsal:
> Hi:
>
> We know volatile is very harmful for optimizers and it is the default
> value (and safest value) if the user doesn't provide that. Asking user
> to set the value is not a good experience, is it possible to auto-generate
> the value
Hi:
We know volatile is very harmful for optimizers and it is the default
value (and safest value) if the user doesn't provide that. Asking user
to set the value is not a good experience, is it possible to auto-generate
the value for it rather than use the volatile directly for user defined
13 matches
Mail list logo
