-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose API to subscribe to Postgres notice messages #570
Comments
FWIW, it's possible to lose NOTICE messages. I prefer logical replication for this problem. But that would entail putting the data into a table |
Do you have more details on that? I was under the assumption that notice messages are side products in the form of out-of-band data as result of exchanging commands with Postgres (such as conversion warnings). Is there an API to capture these with PGJDBC? |
Reading notices with JDBC is a bit convoluted, as they are stored in
(To correctly access and clean up
(Actually, the choice to use R2dbc instead of Jdbc was forced by the implementation in Spring Data that forbids streaming records from Postgres connections, not by the implementation quirks above) |
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
We could probably allow generic listeners for |
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
There are two issues bugging me about this:
Given the above, we could address the code duplication in the proposed PR, by abstracting the common logic between
|
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
Hi, do you have any update on this issue? What's your opinion about my last considerations? |
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
[resolves pgjdbc#570] Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands. Notices travel on the same backend messaging subsystem used by notifications. The implementation processes NoticeResponse in a way similar to NotificationResponse, and exposes a coherent API.
With the availability of the Segment API, it makes sense to expose notices through connection.createStatement("DO language plpgsql $$\n" +
"BEGIN\n" +
" RAISE NOTICE 'hello, world!';\n" +
"END\n" +
"$$;").execute().flatMap(it -> it.flatMap(segment -> {
if (segment instanceof Result.Message) {
return Mono.just(((Result.Message) segment).message());
}
return Mono.empty();
})).as(StepVerifier::create)
.expectNext("hello, world!")
.verifyComplete(); Let me know whether that works for you. |
We now pass-thru NoticeResponse so that notices can be consumed as Result.Message. [#570] Signed-off-by: Mark Paluch <mpaluch@vmware.com>
Add a notices flux to PostgresqlConnection to receive Postgres notice messages.
Postgres may send notice messages through a connection, which may contain log information or metadata related to the submitted commands.
Example use case
A Postgres foreign data wrapper implementation may access external tables stored in multiple files (CSVs, proprietary formats, etc.), and it must send their metadata along with extracted records (type, size, data ranges, etc.). A straightforward implementation would use Postgres notices to send text messages to the client (e.g. in a parsable format like JSON).
Implementation
Notices travel on the same backend messaging subsystem used for notifications. The implementation needs to process
NoticeResponse
s in a way similar toNotificationResponse
s.This implementation choice, with the relative integration tests, is already available in a forked repository.
Example usage
Other
I will open a pull request with the already implemented changes as soon as you accept to evaluate this feature
Best regards
The text was updated successfully, but these errors were encountered: