Renan Alves Fonseca writes:
> There is a Note that says: "The entire body of an SQL function is
> parsed before any of it is executed. While an SQL function can contain
> commands that alter ..."
Yup.
> If I understood well [2], then both notes may be discarded together in
> the next version.
N
On Sat, 29 Mar 2025 at 06:00, Evgeny Morozov
wrote:
>
> On 23/03/2025 2:35 pm, David Rowley wrote:
> >> alter table entity_2 add column new_column text;
> > Is this just an example command? You can't add a column to a
> > partition directly.
>
> Yes, it was just the simplest way I could think of
On Mon, Mar 31, 2025 at 9:42 AM Renan Alves Fonseca
wrote:
> I'm not sure if we should mention the fix or if we should mention a
> workaround...
>
Workarounds are ok but my observation is that "this may change in the
future" comments are pointless and should be stricken from the manual
because p
Laurenz Albe writes:
> On Mon, 2025-03-31 at 18:41 +0200, Renan Alves Fonseca wrote:
>> I would add another Note below like:
>> "Except when inlined, an SQL function is always executed with a
>> generic plan. This behavior may not be desired in some situations, and
>> it will be fixed in future ve
On Mon, 2025-03-31 at 18:41 +0200, Renan Alves Fonseca wrote:
> I would add another Note below like:
> "Except when inlined, an SQL function is always executed with a
> generic plan. This behavior may not be desired in some situations, and
> it will be fixed in future versions."
But that is not tr
On Mon, Mar 31, 2025 at 5:10 AM David Rowley wrote:
>
> On Sat, 29 Mar 2025 at 10:30, Renan Alves Fonseca
> wrote:
> > Currently, in the SQL function path the plan is always generic. The
> > planner ignores the function arguments. The plan_cache_mode setting
> > has no effect in this path.
> >
>
David Rowley writes:
> On Sat, 29 Mar 2025 at 10:30, Renan Alves Fonseca
> wrote:
>> Currently, in the SQL function path the plan is always generic. The
>> planner ignores the function arguments. The plan_cache_mode setting
>> has no effect in this path.
>> I agree that the docs should be more ex
On Sat, 29 Mar 2025 at 10:30, Renan Alves Fonseca
wrote:
> Currently, in the SQL function path the plan is always generic. The
> planner ignores the function arguments. The plan_cache_mode setting
> has no effect in this path.
>
> I agree that the docs should be more explicit about this. There is
I've investigated further and found out that the code that processes
SQL functions is completely different from the code that processes SQL
statements. The latter is more efficient, and there is ongoing work to
merge both.
Currently, in the SQL function path the plan is always generic. The
planner
On 23/03/2025 2:35 pm, David Rowley wrote:
>> alter table entity_2 add column new_column text;
> Is this just an example command? You can't add a column to a
> partition directly.
Yes, it was just the simplest way I could think of to take an exclusive
lock. But on this note: I guess it takes a lo
On 3/21/25 09:27, Evgeny Morozov wrote:
I have a list-partitioned table. When I query the base table but filter
by the partition column in a regular SQL query this takes a lock only on
the one partition being queried, as I expect. However, when the exact
same SQL query is run fom a DB function, w
On Sat, 22 Mar 2025 at 05:27, Evgeny Morozov
wrote:
> select read_partition(1); -- This takes shared locks on entity_1 AND
> entity_2
>
> -- select count(*) from entity where part_id = 1; -- but this would only
> take a shared lock only on entity_1
>
> If another session tries something that takes
12 matches
Mail list logo
