Message-ID: From: "sehrope (@sehrope)" To: "pgjdbc/pgjdbc" Date: Wed, 02 Apr 2025 12:07:02 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #3565: Use query to find the current catalog instead of relying on the database in the connection URL or connection properties as this could be different if connected through a pooler or proxy In-Reply-To: References: List-Id: X-GitHub-Author-Login: sehrope X-GitHub-Comment-Id: 2772355546 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3565 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3565#issuecomment-2772355546 Content-Type: text/plain; charset=utf-8 Let me preface this by saying I'm not opposed to this PR ... though thinking about this a couple questions came to mind. What happens if the DB changes? The whole point of this PR is to skip the fixed value in connection properties and pass through to the actual database, potentially bypassing any intermediate connection pool(s). If the pooler reroutes the connection somewhere else then it'd be wrong as we would have cached the previous value. I suppose that type of pooling is less common, but it does come up for things like live migrations and upgrades. There's also a slight change in behavior here. Previously the method was a pass through to `QueryExecutor.getDatabase()` which returned a cached `String` value. Now that we always execute the command on the first call, this means you cannot call this method while the connection is otherwise in use. I'm worried this may lead to some weird edge case where a user runs a query or COPY operation, and then tries to use this data while processing the result. We could resolve this by caching the value at connection startup. But I don't think we want to add more mandatory startup round trips.