Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Hmm. I think this is a reasonable direction to go in, but
> Tom> what about groupingSets and rowMarks?
> groupingSets ultimately contains nothing but numbers which are
> meaningless without reference to the matching groupClause list. So
> "Tom" == Tom Lane writes:
>> Here is a draft patch along those lines; the intent of this one is
>> that no existing walker or mutator should need to change (the change
>> to the dependency code is basically cosmetic I believe, just avoids
>> walking some things twice).
Tom> Hmm. I th
Andrew Gierth writes:
> "Andrew" == Andrew Gierth writes:
> Andrew> We could minimize the chance of breakage in a back-patched fix
> Andrew> by having query_tree_walker/mutator iterate the windowClause
> Andrew> list itself
> Here is a draft patch along those lines; the intent of this one is
> "Andrew" == Andrew Gierth writes:
Andrew> We could minimize the chance of breakage in a back-patched fix
Andrew> by having query_tree_walker/mutator iterate the windowClause
Andrew> list itself
Here is a draft patch along those lines; the intent of this one is that
no existing walker or
> "Tom" == Tom Lane writes:
Tom> However, we need to fix this in all active branches, and I
Tom> definitely agree with minimizing the amount of change to back
Tom> branches. The fact that the minimal change breaks (or exposes an
Tom> oversight in) assign_collations_walker makes it very pl
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Now probably this is never called on utility statements, and maybe
> Tom> there is never a reason for anyone to examine or mutate
> Tom> SortGroupClauses, GroupingSets, or RowMarkClauses, but I'm not
> Tom> sure it's any business of thi
> "Tom" == Tom Lane writes:
Tom> It looks to me that the reason is that query_tree_mutator
Tom> (likewise query_tree_walker) fails to visit query->windowClause,
I noticed this too. I spent some time looking at what might break if
that was changed (found two places so far, see attached draf
Andrew Gierth writes:
> "Alastair" == Alastair McKinley writes:
> Alastair> This appears to be a bug to me.
> Yes, it's a bug, related to function inlining (the select f(3); is not
> inlined and therefore works, but the select * from f(3); is being
> inlined, but the original Param is somehow m
> "Alastair" == Alastair McKinley writes:
Alastair> Hi all,
Alastair> I noticed this strange behaviour whilst trying to write a
Alastair> function for Postgres 11.5 (PostgreSQL 11.5 on
Alastair> x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
Alastair> (Red Hat 4.8.5-36), 64-b
Hi all,
I noticed this strange behaviour whilst trying to write a function for Postgres
11.5 (PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-36), 64-bit) and reduced it to this minimal example.
Using a function parameter in the window frame definiti
10 matches
Mail list logo
