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 |
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) |