From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dave Cramer <davecramer(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: request for database identifier in the startup packet |
Date: | 2024-05-09 19:39:20 |
Message-ID: | CA+Tgmobh-Dfy_jQOUacSNzo_aUYi=LF6RYQeD18jFZG_0NxDtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 9, 2024 at 3:33 PM Dave Cramer <davecramer(at)gmail(dot)com> wrote:
> On Thu, 9 May 2024 at 15:19, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, May 9, 2024 at 3:14 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> > ISTM that you could just as well query the information you'd like after
>> > connecting. And that's going to be a lot more flexible than having to have
>> > precisely the right information in the startup message, and most clients not
>> > needing it.
>>
>> I agree with this.
>>
> Well other than the extra round trip.
I mean, sure, but we can't avoid that for everyone for everything.
There might be some way of doing something like this with, for
example, the infrastructure that was proposed to dynamically add stuff
to the list of PGC_REPORT GUCs, if the values you need are GUCs
already, or were made so. But I think it's just not workable to
unconditionally add a bunch of things to the startup packet. It'll
just grow and grow.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-05-09 19:39:54 | Re: open items |
Previous Message | Tom Lane | 2024-05-09 19:39:03 | Re: Bug: PGTYPEStimestamp_from_asc() in ECPG pgtypelib |