From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> |
Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Kevin Wooten <kdubb(at)me(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Backend protocol wanted features |
Date: | 2016-01-05 16:31:56 |
Message-ID: | CADK3HHJo2X3dLw4NxaUS+5VWb+qKVEm3gv3DU6Q6fB2ajrgyUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 5 January 2016 at 11:07, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:
>
> On 05/01/16 15:35, Vladimir Sitnikov wrote:
>
>> So rather than asking everybody to add new messages to the protocol to
>>> support this, wouldn't it be better to support LD in the driver?
>>>
>> Well, it would still require to wrap one's mind around to get that
>> efficient.
>> You do not like to deallocate all server-prepared statements after
>> each DDL, do you?
>> On the other hand, JDBC driver does not know changes to which
>> tables/views/functions/types would impact statements prepared in
>> current session, thus JDBC driver has no idea which changes it should
>> subscribe to.
>>
>
> That's a tough question whether to drop or re-create prepared
> statements if they point to database objects that have been modified.
> Needless to say, the naive approach is to drop them all and re-create them
> when required. Any more clever algorithm than this one would be an
> improvements.
>
> However, I still fail to see how this is related to how to acquire the
> knowledge of schema changes. Whether you get it via v4 protocol messages or
> LD, either way, you have the same problem with the prepared statements.
> And, in any case, if schema changes were to be implemented as part of the
> protocol, it would surely be push messages sent asynchronously. Not that
> different from consuming LD.
>
> My point is that I envision strong opposition to add duplicate
> functionality. If schema changes could be obtained from LD, I presume there
> will be opposition to *also* add it to the protocol just because it may not
> be a great fit for the JDBC driver.
This is a systemic problem that we need to figure out. JDBC is arguably one
of the top clients for PostgreSQL, but seems to be treated by a second
class citizen. I don't think it should be necessary to make a second
connection to the backend just to get schema changes.
Dave
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GÜNDÜZ | 2016-01-05 19:46:55 | Re: Are pgrpm changes for JDBC discussed here before submission? |
Previous Message | John Harvey | 2016-01-05 16:19:30 | Re: Are pgrpm changes for JDBC discussed here before submission? |