RE: Psql meta-command conninfo+

Поиск
Список
Период
Сортировка
От Maiquel Grassi
Тема RE: Psql meta-command conninfo+
Дата
Msg-id CP8P284MB24968D07114AEF73D3160896ECF22@CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM
обсуждение исходный текст
Ответ на Re: Psql meta-command conninfo+  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Ответы Re: Psql meta-command conninfo+
Список pgsql-hackers
Hi,

Is there someone willing to help me with this development and guide the patch so that it can be committed one day?

Regards,
Maiquel.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: 001_rep_changes.pl fails due to publisher stuck on shutdown
Следующее
От: Alexander Korotkov
Дата:
Сообщение: 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...