pgjdbc/pgjdbc GitHub issues and pull requests (mirror)help / color / mirror / Atom feed
[pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema 11+ messages / 3 participants [nested] [flat]
* [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-03-18 22:33 "davecramer (@davecramer)" <[email protected]> 0 siblings, 0 replies; 11+ messages in thread From: davecramer (@davecramer) @ 2025-03-18 22:33 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-03-19 09:56 "vlsi (@vlsi)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: vlsi (@vlsi) @ 2025-03-19 09:56 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> Could you add tests? It is unclear why would we want parsing typenames ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-03-19 11:08 "davecramer (@davecramer)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: davecramer (@davecramer) @ 2025-03-19 11:08 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> fixes https://github.com/pgjdbc/pgjdbc/issues/3562 ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-02 12:17 "davecramer (@davecramer)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: davecramer (@davecramer) @ 2025-04-02 12:17 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> So the problem with this is that we presume that the current schema would be 'public'. Now we can add code to check for the current schema but then when we change the schema we would have to invalidate the cache. That might not be the worst thing in the world. Thoughts ? @vlsi @sehrope ? ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-02 12:28 "sehrope (@sehrope)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: sehrope (@sehrope) @ 2025-04-02 12:28 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> Does this always get called with a fully qualified name? If so that seems the correct thing to do here. Otherwise how do you deal with oddball edge cases like `public` no longer being in the search path? Note how the server respects the search path to determine how to refer to an object: ``` => SELECT 'person'::regclass::oid; oid ------- 20768 (1 row) => SELECT 20768::oid::regclass; regclass ---------- person (1 row) => SET search_path = '$user$'; SET => SELECT 20768::oid::regclass; regclass --------------- public.person (1 row) ``` Any magic to strip out the `public` bit would work the majority of the time due to the default search path, but it would be wrong once any changes to search path happen. Especially if `public` is entirely removed. ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-02 12:33 "davecramer (@davecramer)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: davecramer (@davecramer) @ 2025-04-02 12:33 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> ``` select 'public'= any(current_schemas(false)); ?column? ---------- t ``` can tell us if public is on the search path, but I'm loathe to query the database every time We could update it in setSchema which would catch quite a few cases, but not all. Users are still free to execute `set search_path` on their own ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-02 12:40 "sehrope (@sehrope)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: sehrope (@sehrope) @ 2025-04-02 12:40 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> I think you left out the SQL part of that comment :D The more we think about these metadata functions, the more weird and annoying edge cases we're going to find. The only consistent answers I can think of are: * Always query everything at point of use * Always cache / infer everything using initial search path etc The first one sucks as it's likely unneeded 99.99% of the time. The second one will be wrong for any changes to search path etc (but at least it's consistently wrong...). Maybe anybody that does that stuff should really be querying the catalogs in their application code as they're already doing non-JDBC specific actions right? ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-02 12:59 "davecramer (@davecramer)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: davecramer (@davecramer) @ 2025-04-02 12:59 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> > I think you left out the SQL part of that comment :D No just crappy formatting > > The more we think about these metadata functions, the more weird and annoying edge cases we're going to find. The only consistent answers I can think of are: > > * Always query everything at point of use > * Always cache / infer everything using initial search path etc > > The first one sucks as it's likely unneeded 99.99% of the time. The second one will be wrong for any changes to search path etc (but at least it's consistently wrong...). Maybe anybody that does that stuff should really be querying the catalogs in their application code as they're already doing non-JDBC specific actions right? I think I'm aligned with this approach ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-09 17:49 "vlsi (@vlsi)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: vlsi (@vlsi) @ 2025-04-09 17:49 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> (on pgjdbc/src/main/java/org/postgresql/jdbc/TypeInfoCache.java:540) What is the reason for an explicit `startsWith` check here? Could you add tests that exercise it? If you still want to compare it, I would suggest `String.regionMatches(ignoreCase=true, ...`, so it does not need to convert the thing to lowercase on every invocation. ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-09 17:53 "vlsi (@vlsi)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: vlsi (@vlsi) @ 2025-04-09 17:53 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> (on pgjdbc/src/main/java/org/postgresql/jdbc/TypeInfoCache.java:548) What is the reason to put a truncated type name into the cache? If someone calls the function with a full name like `"public"."typename"`, then it would always end up with `getOidStatement` which is unwanted. ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema @ 2025-04-09 17:56 "vlsi (@vlsi)" <[email protected]> 9 siblings, 0 replies; 11+ messages in thread From: vlsi (@vlsi) @ 2025-04-09 17:56 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> (on pgjdbc/src/test/java/org/postgresql/test/jdbc3/CompositeTest.java:86) Could you please clarify how does this test differ from `org.postgresql.test.jdbc2.CustomTypeWithBinaryTransferTest#testCustomBinaryTypes` ? ^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2025-04-09 17:56 UTC | newest] Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-18 22:33 [pgjdbc/pgjdbc] PR #3568: use pgType instead of internal name to preserve the schema "davecramer (@davecramer)" <[email protected]> 2025-03-19 09:56 ` "vlsi (@vlsi)" <[email protected]> 2025-03-19 11:08 ` "davecramer (@davecramer)" <[email protected]> 2025-04-02 12:17 ` "davecramer (@davecramer)" <[email protected]> 2025-04-02 12:28 ` "sehrope (@sehrope)" <[email protected]> 2025-04-02 12:33 ` "davecramer (@davecramer)" <[email protected]> 2025-04-02 12:40 ` "sehrope (@sehrope)" <[email protected]> 2025-04-02 12:59 ` "davecramer (@davecramer)" <[email protected]> 2025-04-09 17:49 ` "vlsi (@vlsi)" <[email protected]> 2025-04-09 17:53 ` "vlsi (@vlsi)" <[email protected]> 2025-04-09 17:56 ` "vlsi (@vlsi)" <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox