Subject: [pgjdbc/pgjdbc] PR #2646: feat: improve libpq compatibility for URL parsing, environment variables, passfile, and property naming

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Thu, 20 Oct 2022 19:12:49 +0000

### 1. Compatibility with libpq is improved regarding URL syntax and resolving url values
####  1.1. `user` and `password` are supported

Complete syntax:
`jdbc:postgresql://[[user][:password]@][host1[:port1][,host2[:port2]][,...]][/database][?property1=value1[&property2=value2][&...]]`

URL may include:

`user` (Optional) is the user to connect. Defaults to operating system username.
`password` (Optional) is the password to connect. No default value.

#### 1.2. property `passfile` is supported

Example:
```
Properties props = new Properties();
PGProperty.PASSFILE.set(props, "/mydir/mypass");
Connection conn = DriverManager.getConnection(url, props);
```

#### 1.3. Code is more clear regarding Properties override rules (source and result are logged at FINE logging level)

There are multiple sources for connection properties. If same property is specified in multiple sources then highest priority source is used. Priority list is here:

```
1) URL arguments (values after `?` mark)
2) URL values (values before `?` mark)
3) Properties given to `DriverManager.getConnection()`
4) values provided by `service` (from resource `.pg_service.conf`)
5) values in Java System Properties
6) values in Operating System environment
7) values from driverconfig file(s) (`org/postgresql/driverconfig.properties`)
8) global defaults (`dbname`, `host`, `pgpass`, `port`, `user`)
```

#### 1.4. References

Related to: #2260 #2278 #2398 #2393 #2395 #2424 #2569 #2641 #2644

### All Submissions:

* [x] Have you followed the guidelines in our [Contributing](https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md) document?
* [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?

### New Feature Submissions:

1. [x] Does your submission pass tests?
2. [x] Does `./gradlew autostyleCheck checkstyleAll` pass ?
6. [x] Have you added your new test classes to an existing test suite in alphabetical order?

### Changes to Existing Features:

* [x] Have you added an explanation of what your changes do and why you'd like us to include them?
* [x] Have you written new tests for your core changes, as applicable?
* [x] Have you successfully run tests with your changes locally?

---

From: "gitguardian[bot] (bot) (@gitguardian[bot])" <noreply+gitguardian[bot]@github.com>
Date: Thu, 20 Oct 2022 19:13:38 +0000

#### ⚠️ GitGuardian has uncovered 9 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

<details>
<summary>🔎 Detected hardcoded secrets in your pull request</summary>
<br>

| GitGuardian id | GitGuardian status | Secret                         | Commit           | Filename        |                      |
| -------------- | ------------------ | ------------------------------ | ---------------- | --------------- | -------------------- |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | PostgreSQL Credentials | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R262) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R171) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R107) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | PostgreSQL Credentials | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R251) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/resources/pg_service/pgservicefileProps.conf | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-383f6df5ed2e099c7b9906f385d7456066f491e5ae92704cab6e583278875c27R36) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R386) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Database Assignment | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R243) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/resources/pg_service/pgservicefileProps.conf | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-383f6df5ed2e099c7b9906f385d7456066f491e5ae92704cab6e583278875c27R45) |
| [-](https://dashboard.gitguardian.com/workspace/59849/incidents/secrets) | - | Generic Password | 0626960921d42633e07ec5bb6ddd47d97a6f7a16 | pgjdbc/src/test/java/org/postgresql/jdbcurlresolver/JdbcUrlResolverTest.java | [View secret](https://github.com/pgjdbc/pgjdbc/commit/0626960921d42633e07ec5bb6ddd47d97a6f7a16#diff-4531a18c3790df967473ac9aed3ea99a5dbfdf0919aa1b86cbaa42a24331eed1R104) |

</details>

<details>
<summary>🛠 Guidelines to remediate hardcoded secrets</summary>
<br>

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. [Learn here](https://blog.gitguardian.com/secrets-api-management?utm_source=product&amp;utm_medium=GitHub_checks&amp;utm_campaign=check_run_comment) the best practices.
3. Revoke and [rotate these secrets](https://docs.gitguardian.com/secrets-detection/secrets-detection-engine/detectors/specifics/postgres_uri#revoke-the-secret?utm_source=product&amp;utm_medium=GitHub_checks&amp;utm_campaign=check_run_comment).
4. If possible, [rewrite git history](https://blog.gitguardian.com/rewriting-git-history-cheatsheet?utm_source=product&amp;utm_medium=GitHub_checks&amp;utm_campaign=check_run_comment). Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

-   following these [best practices](https://blog.gitguardian.com/secrets-api-management/?utm_source=product&amp;utm_medium=GitHub_checks&amp;utm_campaign=check_run_comment) for managing and storing secrets including API keys and other credentials
-   install [secret detection on pre-commit](https://docs.gitguardian.com/ggshield-docs/integrations/git-hooks/pre-commit?utm_source=product&amp;utm_medium=GitHub_checks&amp;utm_campaign=check_run_comment) to catch secret before it leaves your machine and ease remediation.

</details>

---

<sup>🦉 [GitGuardian](https://dashboard.gitguardian.com/auth/login/?utm_medium=checkruns&amp;utm_source=github&amp;utm_campaign=cr1) detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.<br/></sup>

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 20 Oct 2022 20:45:34 +0000

(on pgjdbc/src/main/java/org/postgresql/jdbcurlresolver/PgPassParser.java:80)

If we are looking to provide psql compatibility we should probably check the permissions of the file to ensure they are 0600 on *nix systems.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Sat, 22 Oct 2022 10:52:10 +0000

Good observation. Permission check is added: https://github.com/pgjdbc/pgjdbc/compare/581edc3..736f2cb

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Fri, 06 Jan 2023 16:18:20 +0000

@davecramer 
Hi! What are merge plans? Should I resolve conflicts now or at a later time?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 06 Jan 2023 16:23:29 +0000

@MarekUniq currently my plans are 1) merge in the issue with longs https://github.com/pgjdbc/pgjdbc/pull/2710 will be reopened and merged. A release with this fix will be released. 
Then we plan on merging in https://github.com/pgjdbc/pgjdbc/pull/2635 and releasing as a new major version.

I would hold off rebasing until after the above happens.

Thanks for your patience

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 06 Jun 2023 13:43:06 +0000

@davecramer 
Hi! The following pull requests are merged: #2710 #2635.
Any plans for this one?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 16 Jan 2024 19:41:54 +0000

@davecramer Hi! What are merge plans?

---

From: "androa (@androa)" <[email-masked]>
Date: Thu, 18 Apr 2024 06:50:50 +0000

Is there any progress on merging this?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 18 Apr 2024 13:09:28 +0000

I'm generally in favour of this PR. It will need to be rebased.

---

From: "sehrope (@sehrope)" <[email-masked]>
Date: Thu, 18 Apr 2024 13:29:33 +0000

(on pgjdbc/src/test/java/org/postgresql/test/jdbc2/DriverTest.java)

How about adding an overload for the old private `verifyUrl(...)` to call the new one?

```java
private void verifyUrl(Driver drv, String url, String hosts, String ports, String dbName) {
    verifyUrl(drv, url, hosts, ports, dbName, "osUser", null);
}
```

That way the majority of the above test cases would not duplicate that info and it would better showcase that none of the expected behavior for those tests have changed.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Sun, 12 May 2024 19:49:31 +0000

> @davecramer: I'm generally in favour of this PR. It will need to be rebased.
Rebased

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Sun, 12 May 2024 19:52:37 +0000

@MarekUniq , the change reads `+19,305 −44,408`. Please make sure you include only the needed changes. There's no way we merge something that touches 44 thousand lines.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Sun, 12 May 2024 21:17:11 +0000

@vlsi - I agree that GitHub displayed this PR in a strange way. I saw it too. (was it a glitch or my mistake, I do not know)

But I noticed there were 5 new commits in `master` branch and I rebased branch `feature/urlparser-improve3-pr2` again.
the change reads are back to normal now:
`+2,031 −909`

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:38:40 +0000

@MarekUniq , please rebase commits so they appear "on top of the master branch". The project uses linear history rather than merge commits.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:47:26 +0000

(on README.md)

Why the full table appears to be changed?
Can we please avoid re-formatting the table with every commit that touches it?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:47:39 +0000

(on README.md)

Please just change the lines you want to change. Keep the reset intact.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:48:24 +0000

(on README.md)

What does "env vars can be set" mean? What does it give to the end users?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:49:49 +0000

(on pgjdbc/src/main/java/org/postgresql/PGProperty.java:503)

What happens to the code that still uses `PGHOST` and `PGPORT` properties? Will it continue to work? Where's the corresponding test case?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 07:57:18 +0000

(on pgjdbc/src/main/java/org/postgresql/jdbcurlresolver/PgPassParser.java)

I suggest we log the current value along with the desired one

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 08:00:01 +0000

(on pgjdbc/src/main/java/org/postgresql/ds/common/BaseDataSource.java:1568)

This is a backward incompatible change. Old code might still call `setProperty(PGProperty.PG_HOST, ...)` and it should continue to work as expected.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Mon, 13 May 2024 15:47:34 +0000

(on README.md)

it is about improving compatibility with libpq
> What does "env vars can be set" mean? 
```
# An example of setting environment variables:
export PGUSER=my_user
export PGPASSWORD=my_password
```
> What does it give to the end users?
```
# then jdbc and libpq-based programs can be launched identically:
java ... MainJdbcBasedProgram
./main_libpq_based_program
```

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 13 May 2024 15:53:49 +0000

(on README.md)

What I mean is that it would be better to phrase the features in terms of their usability.
The fact that environment variable can be set does not provide much to the end users.

It might be better to have something like "Some of the settings could be passed from environment variables as follows:..."

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 14 May 2024 18:41:47 +0000

Thank you for finding!
Added fix and test case in commit: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/4b294497f94545151bfd73c62407d5fbe266d7d7

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 14 May 2024 19:07:42 +0000

(on README.md)

Original spaces restored with commit: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/0eac4e3d1fbc0f33f2da9c08f43648c4821ca38b

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 14 May 2024 19:23:34 +0000

current value is logged now: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/a81210d89dfe20c5c2ed22976639ea7e306c4a63

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Wed, 15 May 2024 06:25:32 +0000

(on README.md)

Is it good enough: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/3db232a53641c86c8183cbf6b88caf4cb503cc71

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 15 May 2024 06:29:21 +0000

(on pgjdbc/src/main/java/org/postgresql/util/PGPropertyUtil.java:20)

Class removal is a backward-incompatible change

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 15 May 2024 06:30:15 +0000

The key question I have here is how do we test and ensure backward compatibility?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Wed, 15 May 2024 18:50:24 +0000

In broad terms, you are correct. However, this class was intended for internal use only. It is not a JDBC driver service provided for external clients.

I can restore this class (and optionally mar methods as deprecated).
What are your expectations here?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Wed, 15 May 2024 18:57:08 +0000

> @MarekUniq , please rebase commits so they appear "on top of the master branch". The project uses linear history rather than merge commits.

@vlsi I think I can't change the order of commits anymore.
However, in case this PR will be merged, there will be a "squash merge" and then there will be only one commit in the master branch, which will appear as the last commit in the master branch. Isn't it?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 15 May 2024 19:13:18 +0000

The class was public, so people might be using it. We must maintain backward compatibility

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 15 May 2024 19:14:34 +0000

What do you mean by "can't change the order of commits"? Could you please squash at your side?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Sat, 18 May 2024 21:44:07 +0000

duplicate info removed: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/c7413f775fbc901ac952c70880639ca6db9013db

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Wed, 22 May 2024 08:13:43 +0000

class is restored and marked as deprecated

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Wed, 22 May 2024 08:21:36 +0000

> What do you mean by "can't change the order of commits"? Could you please squash at your side?

@vlsi Is this the result you were expecting? I did the following:
- git merge --squash ...
- git push --force ...

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 27 May 2024 09:12:12 +0000

(on pgjdbc/src/main/java/org/postgresql/PGEnvironment.java)

Is this a backward compatible change?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 28 May 2024 08:38:21 +0000

There is no one constant default value for given parameter.
The default value is operating system specific.
**Yes, functionality is backward compatible (the same).**

**Can you recommend proper approach?**
This enum is not meant to be used outside pgjdbc driver.
There should not be any promises assumed regarding this enum outside pgjdbc driver.
At the same time I can not remove keyword `public`.
How could we avoid "backward compatible" questions which are relevant only because of technical restrictions?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 28 May 2024 11:38:36 +0000

test cases and fixes added: https://github.com/pgjdbc/pgjdbc/pull/2646/commits/e9676f259dad716e29d1cee12e809fab9de50351

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Tue, 28 May 2024 12:47:07 +0000

>This enum is not meant to be used outside pgjdbc driver.

The enum is public, it is located in a public `org.postgresql` package, nothing in its javadoc says anything regarding "for pgjdbc internal use only" and so on.

There might be usages of the enum outside of the driver.

---

>How could we avoid "backward compatible" questions which are relevant only because of technical restrictions?

I do not understand the question.
I think the only case we can merge a PR is if the PR keeps full backward compatibility or if the breakage is minimal.

If there's a significant breakage of the backward compatibility, there's very little we can do.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Fri, 31 May 2024 13:15:19 +0000

> The enum is public, it is located in a public org.postgresql package, nothing in its javadoc says anything regarding "for pgjdbc internal use only" and so on.

Exactly, this was the point of my question.

There is an enum. It is meant to be used only internally by pgjdbc project.
But, I have to make enum `public` because it is used by different packages inside pgjdbc project (technical/language limitation)
Javadoc etc is soft restriction, public enum can still be used. 

I was wondering if there was an approach to the problem described above. How should we create classes/enums that are used by different packages in the pgjdbc project internally, but when renaming/moving/deleting them, the issue of "backward compatibility" is irrelevant.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Fri, 31 May 2024 13:28:11 +0000

> ... is if the PR keeps full backward compatibility or if the breakage is minimal.

In my estimation, the real impact is close to zero.
The old value is incorrect and there is no common constant default value for this parameter across all operating systems.
If someone has adopted this default value and has tested their system, they must have realized that this value is wrong

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 04 Jun 2024 06:31:25 +0000

@davecramer @sehrope @vlsi 
>From my point of view, I have nothing pending or anything to add regarding this PR at this time.
Please continue with the PR review process and provide feedback or suggest necessary changes as needed.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Tue, 04 Jun 2024 07:16:06 +0000

It does not have to work across all the OS. It might work for a single os, so changing default might break user's workfows.

We focus on backward compatibility, so breaking things like "property no longer used" or "enum entry no longer exists" makes it much harder to merge the change.

Could you please double-check if the PR maintains backward compatibility?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Fri, 07 Jun 2024 06:35:56 +0000

The "old" default value is incorrect for all major operating systems: Linux, Windows, and MacOS.
A bit more correct value would be: `.pg_service.conf`
Correct value would be: `${HOME}/.pg_service.conf` for Linux/MacOS and `%APPDATA%\postgresql\.pg_service.conf` for Windows

I disagree that maintaining this incorrect default value is necessary, but since it seems to be a blocking issue, I have reverted code to keep the incorrect "old" default value.

Additionally, I have marked the `getDefaultValue()` function as deprecated.
This serves as a reminder that in the next major version, both the function and the incorrect default value may be removed from the code.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Mon, 09 Sep 2024 08:14:20 +0000

@davecramer @vlsi Hello! I'm interested in the status of this pull request. Are there any updates or plans for merging it? I'm happy to help with addressing outstanding issues.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 09 Sep 2024 10:59:58 +0000

@MarekUniq I will have to spend some time reviewing this again.

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Tue, 18 Mar 2025 14:46:45 +0000

Hello! I'm interested in the status of this pull request. Are there any updates or plans for merging it? I'm happy to help with addressing outstanding issues.

---

From: "mmand (@mmand)" <[email-masked]>
Date: Fri, 20 Jun 2025 13:27:09 +0000

Hi! What are the plans for merging this pull request?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Thu, 16 Oct 2025 06:53:58 +0000

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 17 Oct 2025 12:20:13 +0000

I'm in favour of this PR. There is one failing test however that does look like one of yours?

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Thu, 23 Oct 2025 11:46:31 +0000

@davecramer The test that failed in the Java 25 environment has been fixed. All tests are now green.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 24 Oct 2025 05:34:39 +0000

@MarekUniq thanks! We will review the PR soon

---

From: "MarekUniq (@MarekUniq)" <[email-masked]>
Date: Fri, 20 Mar 2026 19:01:32 +0000

@davecramer @vlsi Thanks for the positive feedback and for planning a review.

Given that this PR has been open since 2022, could you clarify whether there is a realistic plan to move it forward?

I’m trying to decide whether it makes sense to continue actively maintaining and rebasing it. In cases where file structures change, rebasing becomes a significant time investment, so I’d like to understand if that effort is justified at this point.

Appreciate any guidance here.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 23 Mar 2026 17:05:53 +0000

@MarekUniq , the change addresses true issues, so it should be merged sooner or later.
Many thanks for pushing this forward.

There's challenge with maintaining backward compatibility though.
We do not want breaking the apps by merging a PR that adjusts property names.

---

Findings so far:
1) It looks like `PgProperty.PG_DBNAME`, `PgProperty.PG_PORT`, `PgProperty.PG_HOST` are wildly used across GitHub repositories, so I am leaning towards un-deprecating them. In other words, we should probably keep them as is, discourage their use in javadoc, and avoid adding `@deprecated` so users don't have to adjust `PgProperty.PG_PORT` -> `PgProperty.PORT` all over the place
2) We need to test somehow that newly added `PgProperty.PORT`-like properties work exactly the same as `PgProperty.PG_PORT`. The existing tests refer to `PgProperty.PG_PORT`, and it is fine to test backward compatibility. However, we should ensure the new ones work
3) `acceptsURL()` can now reject a syntactically valid URL because of external service config. This might be the case like "it worked previously, and now it starts failing"
4) Unknown keys in the Properties argument now cause URL parsing to fail. Previously they were silently ignored, and now they produce failures
5) We should double-check that `System.getProperty("user.name")` still works as a default username. Previously it was working like that, and it looks like `System.getProperty("user.name")` was removed from `Driver.java` for some reason
6) `PGProperty.removeNonExistingProperties` should likely be renamed: it does not remove properties but creates a new `Properties` instance
7) `PGPASSFILE.getDefaultValue()` changed from `"pgpass"` to `null`, and the method is now `@Deprecated`. Code calling `PGEnvironment.PGPASSFILE.getDefaultValue()` will get `null` instead of `"pgpass"`.
8) `Driver.parseURL` was static, and the PR seems to change the names of the properties in the results.
External code doing `props.getProperty("PGHOST")` after `Driver.parseURL()` will break.
9) `PgPassParser` and `PgServiceConfParser` made package-private. 
10) Service file not found = fatal error. Previously, if no .pg_service.conf file was found, PgServiceConfParser returned null and the driver continued silently. Now it throws JdbcUrlResolverFatalException("Resource file [.pg_service.conf] not found"). This means ?service=foo fails hard if the file doesn't exist, which is correct behavior (matches libpq), but is a change from the previous lenient behavior.

---

Frankly, my current understanding is that "fail on error" (==fail on unsupported property, or fail on missing `.pg_service.conf`) should be opt-in, and users should explicitly opt-in to that behavior change