From 4ee2a9d1cfd089f49767a21cfb070e42ef512317 Mon Sep 17 00:00:00 2001 From: Chapman Flack Date: Sat, 16 Sep 2023 22:47:10 -0400 Subject: [PATCH 1/4] Allow use of Node with either PGJDBC or pgjdbc-ng The two drivers use slightly different URL syntax, and different names for some properties (database.name vs. PGDBNAME, and application.name vs. ApplicationName matter here). Expose a new static s_urlForm and constants URL_FORM_PGJDBC and URL_FORM_PGJDBCNG (and URL_FORM_NONE if no recognized driver has been found) so a client can know what's been selected. To simply count the otherwise-unwanted rows of a ResultSet, pgjdbc-ng allows rs.last();rs.getRow(); but PGJDBC does not, at least under its default for ResultSet scrollability. The method voidResultSetDims gets a change here to not attempt to count the rows when called by peek(); instead, it just returns -1 for rows in that case, which will look odd but play well with both drivers. The PostgreSQL backend sends an interesting message in the case of function/procedure creation with types mentioned that are shells. The message has severity NOTICE but SQLState 42809 (ERRCODE_WRONG_OBJECT_TYPE). For some reason, pgjdbc-ng has not been delivering those, but PGJDBC does, and the heuristic of looking at the class digits to decide if it's ok or not would make the wrong call seeing class 42. Happily, PGJDBC exposes (by casting to PGJDBC-specific types) the severity tag from the backend. So that has to be done here, and done reflectively, to avoid a hard PGJDBC dependency. PGJDBC exposes the SEVERITY (S) tag, but not the SEVERITY_NONLOCALIZED (V) tag that was added in PG 10 (postgres/postgres@26fa446). The upshot is that the rule used here to recognize WARNING will fail if the backend is using a language where it's some other word. A new static method set_WARNING_localized can be used to set the correct tag (PERINGATAN in Indonesian, for example) so the classification will happen correctly for the language selected in the backend. For utility statements with no result, where in pgjdbc-ng there really is no result, in PGJDBC there is a zero row count, the same as for a DML statement that touched no rows. It'll take another commit to make the test state machines work either way. --- pljava-packaging/pom.xml | 17 ++ pljava-packaging/src/main/java/Node.java | 238 +++++++++++++++++++++-- 2 files changed, 235 insertions(+), 20 deletions(-) diff --git a/pljava-packaging/pom.xml b/pljava-packaging/pom.xml index b7262e705..ee19ad959 100644 --- a/pljava-packaging/pom.xml +++ b/pljava-packaging/pom.xml @@ -64,6 +64,23 @@ + + + pgjdbc + + + org.postgresql + postgresql + [42.6.0,) + + + +