Re: proposal: psql: show current user in prompt

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jelte Fennema <postgres(at)jeltef(dot)nl>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kirk Wolak <wolakk(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: psql: show current user in prompt
Date: 2023-09-11 19:30:48
Message-ID: CAFj8pRAX48WH5Y6BbqnZbUSzmtEaQZ22rY_6cYw=E9QkoVvL0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 11. 9. 2023 v 13:24 odesílatel Jelte Fennema <postgres(at)jeltef(dot)nl> napsal:

> On Fri, 8 Sept 2023 at 21:08, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > ok changed - there is minor problem - almost all PQ functions are of int
> type, but ProtocolVersion is uint
>
> Your current implementation requires using the PG_PROTOCOL macros to
> compare versions. But clients cannot currently use those macros since
> they are not exported from libpq-fe.h, only from pqcomm.h which is
> then imported by libpq-int.h. (psql/command.c imports pcomm.h
> directly, but I don't think we should expect clients to do that). We
> could ofcourse export these macros from libpq-fe.h too. But then we'd
> need to document those macros too.
>
> > Using different mapping to int can be problematic - can be messy if we
> cannot use PG_PROTOCOL macro.
>
> I see no big problems returning an unsigned or long from the new
> function (even if existing functions all returned int). But I don't
> even think that is necessary. Returning the following as an int from
> PQprotocolVersionFull would work fine afaict:
>
> return PG_PROTOCOL_MAJOR(version) * 1000 + PG_PROTOCOL_MINOR(version)
>
> This would give us one thousand minor versions for each major version.
> This seems fine for all practical purposes. Since postgres only
> releases a version once every year, we'd need a protocol bump every
> year for one thousand years for that to ever cause any problems. So
> I'd prefer this approach over making the PG_PROTOCOL macros a public
> interface.
>

I did proposed change

Regards

Pavel

Attachment Content-Type Size
v20230911-0004-Implementation-of-N-prompt-placeholder.patch text/x-patch 5.7 KB
v20230911-0001-Protocol-ReportGUC-message.patch text/x-patch 11.2 KB
v20230911-0003-allow-to-connect-to-server-with-major-protocol-versi.patch text/x-patch 6.5 KB
v20230911-0002-PQlinkParameterStatus-PQunlinkParameterStatus-test-b.patch text/x-patch 5.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-09-11 20:52:50 Re: Query execution in Perl TAP tests needs work
Previous Message Jeff Davis 2023-09-11 19:15:49 Re: Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c)