Re: Backend protocol wanted features

Поиск
Список
Период
Сортировка
От Álvaro Hernández Tortosa
Тема Re: Backend protocol wanted features
Дата
Msg-id 568C63C4.3040703@8Kdata.com
обсуждение исходный текст
Ответ на Re: Backend protocol wanted features  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: Backend protocol wanted features  (Sehrope Sarkuni <sehrope@jackdb.com>)
Список pgsql-jdbc

On 05/01/16 17:31, Dave Cramer wrote:

On 5 January 2016 at 11:07, Álvaro Hernández Tortosa <aht@8kdata.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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Devrim GÜNDÜZ
Дата:
Сообщение: Re: Are pgrpm changes for JDBC discussed here before submission?
Следующее
От: Álvaro Hernández Tortosa
Дата:
Сообщение: Re: