Message-ID: From: "sehrope (@sehrope)" To: "pgjdbc/pgjdbc" Date: Fri, 22 May 2026 12:00:56 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #4077: pgjdbc: introduce @PgApi / @PgTags / @PgPropertyType annotations on PGProperty In-Reply-To: References: List-Id: X-GitHub-Author-Login: sehrope X-GitHub-Comment-Id: 4518458836 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 4077 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4077#issuecomment-4518458836 Content-Type: text/plain; charset=utf-8 Besides the data type piece, I don't think this makes sense. We do not introduce anything as a property that is not stable. We're not going to have experimental properties released and then removed or linger. If there's an experiment branch with a property, that can be a snapshot release of the jar for people to test out. It's not going to be a published thing in the driver. Ditto for "hidden". It's either there or it's not. There's no secret properties. If something should not be used it can be `@Deprecated`. If we remove things, it's a conscious breaking change. The topic tags would be useful for an automated doc site. I haven't actually looked them individually to see if the meaning align with the properties. So ignoring that for now. I think the `PgPropertyType` may be better named as "DataType" or "ValueType" to reflect the intent. And having it be a runtime annotation would allow it to be used for runtime validation of the value to standardize the checks and error messages. It could be "integer", "positive integer", "string", "boolean", ... or even "second" etc. We'd have to be careful here if there's special values out of range though (e.g., "seconds" would normally be >=0 but maybe -1 has special meaning). Having those types exposed to the user could be a useful feature. User applications could use it to dynamically provide connection options. Not just the names, but structured validation of the values. It's not a light decision though as we'd clearly be increasing the surface area of the driver to include this new enum. So would want to think about this for a bit before proceeding.