Mailing lists [pgsql-hackers]
- Re: Need clarification on compilation errors in PG 16.2 Daniel Gustafsson
- Re: meson vs windows perl Andres Freund
- Re: In-placre persistance change of a relation Jelte Fennema-Nio
- Re: DROP OWNED BY fails to clean out pg_init_privs grants Hannu Krosing
- Re: pgsql: Add more SQL/JSON constructor functions Amit Langote
- Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning Ashutosh Bapat
- Re: Improving the latch handling between logical replication launcher and worker processes. Peter Smith
- Re: Need clarification on compilation errors in PG 16.2 Pradeep Kumar
- Re: Need clarification on compilation errors in PG 16.2 Pradeep Kumar
- Re: meson: Specify -Wformat as a common warning flag for extensions Peter Eisentraut
- meson "experimental"? Peter Eisentraut
- Re: meson: Specify -Wformat as a common warning flag for extensions Sutou Kouhei
- About 0001:,Having overviewed it, I don't see any issues (but I'm the author), except grammatical ones - but I'm not a native to judge it.,Also, the sentence 'turning GROUP BY clauses into pathkeys' is unclear to me. It may be better to write something like: 'building pathkeys by the list of grouping clauses'.,,0002:,The part under USE_ASSERT_CHECKING looks good to me. But the code in group_keys_reorder_by_pathkeys looks suspicious: of course, we do some doubtful work without any possible way to reproduce, but if we envision some duplicated elements in the group_clauses, we should avoid usage of the list_concat_unique_ptr. What's more, why do you not exit from foreach_ptr immediately after SortGroupClause has been found? I think the new_group_clauses should be consistent with the new_group_pathkeys.,,0003:,Looks good,,0004:,I was also thinking about reintroducing the preprocess_groupclause because with the re-arrangement of GROUP-BY clauses according to incoming pathkeys, it doesn't make sense to have a user-defined order—at least while cost_sort doesn't differ costs for alternative column orderings.,So, I'm okay with the code. But why don't you use the same approach with foreach_ptr as before? Andrei Lepikhov
- Re: Improving the latch handling between logical replication launcher and worker processes. vignesh C
- Re: Improving the latch handling between logical replication launcher and worker processes. vignesh C
- Timeout gets unset on a syntax error. ISHAN CHHANGANI .
- 001_rep_changes.pl fails due to publisher stuck on shutdown Alexander Lakhin
- RE: Psql meta-command conninfo+ Maiquel Grassi
- Re: About 0001:,Having overviewed it, I don't see any issues (but I'm the author), except grammatical ones - but I'm not a native to judge it.,Also, the sentence 'turning GROUP BY clauses into pathkeys' is unclear to me. It may be better to write something like: 'building pathkeys by the list of grouping clauses'.,,0002:,The part under USE_ASSERT_CHECKING looks good to me. But the code in group_keys_reorder_by_pathkeys looks suspicious: of course, we do some doubtful work without any possible way to reproduce, but if we envision some duplicated elements in the group_clauses, we should avoid usage of the list_concat_unique_ptr. What's more, why do you not exit from foreach_ptr immediately after SortGroupClause has been found? I think the new_group_clauses should be consistent with the new_group_pathkeys.,,0003:,Looks good,,0004:,I was also thinking about reintroducing the preprocess_groupclause because with the re-arrangement of GROUP-BY clauses according to incoming pathkeys, it d... Alexander Korotkov
- Re: Volatile write caches on macOS and Windows, redux Peter Eisentraut
- Re: 001_rep_changes.pl fails due to publisher stuck on shutdown vignesh C
- Re: pgsql: Add more SQL/JSON constructor functions Tom Lane
- Re: Remove last traces of HPPA support Noah Misch