Postgres Pro
Downloads
Home   >   mailing lists

RE: Psql meta-command conninfo+ - Mailing list pgsql-hackers

From Maiquel Grassi
Subject RE: Psql meta-command conninfo+
Date
Msg-id CP8P284MB24968D07114AEF73D3160896ECF22@CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Psql meta-command conninfo+  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: Psql meta-command conninfo+
List pgsql-hackers
Tree view
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 by date:

Previous
From: Alexander Lakhin
Date:
Subject: 001_rep_changes.pl fails due to publisher stuck on shutdown
Next
From: Alexander Korotkov
Date:
Subject: 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...