On 26.02.24 02:08, Michael Paquier wrote:
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote:
Julien Rouhaud writes:
On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
- funcordinality
This was probably just forgotten. It should be included because the WITH
ORDINALITY
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote:
> Julien Rouhaud writes:
>> On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
>>> - funcordinality
>>> This was probably just forgotten. It should be included because the WITH
>>> ORDINALITY clause changes the query
On Fri, Feb 23, 2024 at 11:00:41PM +0100, Alvaro Herrera wrote:
>
> Another, similar but not quite: if you do
>
> SET search_path TO foo;
> SELECT * FROM t1;
> SET search_path TO bar;
> SELECT * FROM t1;
>
> and you have both foo.t1 and bar.t1, you'll get two identical-looking
> queries in
On 2024-Feb-23, Peter Eisentraut wrote:
> - alias
>
> Currently, two queries like
>
> SELECT * FROM t1 AS foo
> SELECT * FROM t1 AS bar
>
> are counted together by pg_stat_statements -- that might be ok, but they
> both get listed under whichever one is run first, so here if you are looking
>
Julien Rouhaud writes:
> On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
>> - funcordinality
>> This was probably just forgotten. It should be included because the WITH
>> ORDINALITY clause changes the query result.
> Agreed.
Seems OK.
>> - lateral
>> Also probably
Hi,
On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
>
> - alias
>
> Currently, two queries like
>
> SELECT * FROM t1 AS foo
> SELECT * FROM t1 AS bar
>
> are counted together by pg_stat_statements -- that might be ok, but they
> both get listed under whichever one is run first,
I think there are some fields from the RangeTblEntry struct missing in
the jumble (function _jumbleRangeTblEntry()). Probably, some of these
were really just forgotten, in other cases this might be an intentional
decision, but then it might be good to document it. This has come up in
thread
