On Tue, Jul 08, 2025 at 05:41:32PM -0700, Noah Misch wrote:
> I'd prefer not to get involved in decisions affecting only psql efficiency and
> psql code cosmetics. Please make that decision without my input.
Okay, I have used this more extensible routine then, planning to use
it for the other pat
On Tue, Jul 08, 2025 at 08:52:08AM +0900, Michael Paquier wrote:
> On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote:
> > I think the choice to make there is whether to call PQconninfo() once per
> > prompt emission or to cache the value, invalidating that cache e.g. once per
> > SyncVaria
On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote:
> I think the choice to make there is whether to call PQconninfo() once per
> prompt emission or to cache the value, invalidating that cache e.g. once per
> SyncVariables(). My first thought was to cache, but the decision is not too
> imp
On Mon, Jul 07, 2025 at 11:06:06AM +0900, Michael Paquier wrote:
> On Sun, Jul 06, 2025 at 09:13:19AM -0700, Noah Misch wrote:
> > This new PQservice() function from commit 4b99fed75 came up in the annual
> > exports.txt diff. The standard in libpq has been to not clutter the API
> > with
> > new
On Sun, Jul 06, 2025 at 09:13:19AM -0700, Noah Misch wrote:
> This new PQservice() function from commit 4b99fed75 came up in the annual
> exports.txt diff. The standard in libpq has been to not clutter the API with
> new functions that simply retrieve one PQconninfoOption value. PQconninfo()
> pr
On Wed, Dec 18, 2024 at 03:17:36PM +0900, Michael Paquier wrote:
> Done.
This new PQservice() function from commit 4b99fed75 came up in the annual
exports.txt diff. The standard in libpq has been to not clutter the API with
new functions that simply retrieve one PQconninfoOption value. PQconninf
Hi,
On Wed, Dec 18, 2024 at 03:17:36PM +0900, Michael Paquier wrote:
> On Tue, Dec 17, 2024 at 09:42:36AM +0100, Michael Banck wrote:
> > Done.
> >
> > V3 attached.
>
> Done.
Thanks!
Michael
On Tue, Dec 17, 2024 at 09:42:36AM +0100, Michael Banck wrote:
> Done.
>
> V3 attached.
Done.
--
Michael
signature.asc
Description: PGP signature
Hi,
On Tue, Dec 17, 2024 at 04:43:21PM +0900, Michael Paquier wrote:
> On Mon, Dec 16, 2024 at 10:57:49PM +0100, Michael Banck wrote:
> > Thanks, I have added the documentation now in v2.
>
> The doc additions seem fine to me. I've just grabbed three tiny nits,
> nothing critical.
Thanks for th
On Mon, Dec 16, 2024 at 10:57:49PM +0100, Michael Banck wrote:
> Thanks, I have added the documentation now in v2.
The doc additions seem fine to me. I've just grabbed three tiny nits,
nothing critical.
+ case 's':
+ if (PQservi
Hi Michael,
On Tue, Dec 10, 2024 at 04:38:24PM +0900, Michael Paquier wrote:
> On Thu, Nov 28, 2024 at 09:17:23PM +0100, Michael Banck wrote:
> > On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> > > Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
> >
On Thu, Nov 28, 2024 at 09:17:23PM +0100, Michael Banck wrote:
> Hi,
>
> On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> > Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
> > %s was still available. :)
>
> Thanks. Was that full review? You kept the
Hi,
On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
> %s was still available. :)
Thanks. Was that full review? You kept the commitfest item in "Needs
Review" state.
Michael
Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
%s was still available. :)
Cheers,
Greg
Hi,
I think it might be useful to sometimes display the database service
(i.e. what is defined in ~/.pg_service.conf and used via psql
service=foo) in the psql prompt, e.g. if you have 'test' and 'prod'
services, but both have the same database name. This was also suggested
to me during a recent c
15 matches
Mail list logo
