Re: Backend protocol wanted features

On 05/01/16 17:31, Dave Cramer wrote:
>
> On 5 January 2016 at 11:07, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com
> <mailto: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.

If anything, I am a really strong defender of Java and Postgres. So
I would never allow it to be considered a second class citizen. However,
I'm unsure pushing "our" requirements to a broader support for everybody
*when* that can be obtained by other means, may not be enough justification.

There are other parts of the protocol that require a separate
connection. Those I don't like either, but it's not unheard of. Maybe
the solution is different: that LD may be consumed within the same
connection (if that would be possible).

In any case, it won't be me rejecting that messages informing of
schema changes, of course not. I just think they belong more to LD anyway :)

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata