Re: Backend protocol wanted features

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

>
>