Old commented out method should be removed.

s/2018/2019/

Isn't getParameterStatus(String parameterName) just enough?
Is the returned Map live?

The map returned is an unmodifiable wrapper.

If we don't expose the map then we should provide a List<String>-returning call to list known params instead. Just exposing the map is simpler.

What is a bit wonky is the handling of case sensitivity.
While we can certainly provide an implementation of String getParameterStatus(String param) which is case insensitive to param, getting the Map.keySet() off the return value here would return some specific case when iterating values.
I think I would lean towards 1 method to return the known parameters and a separate method to get the value for some given parameter in a case insensitive way.
This provides the needed/desired functionality and hides the implementation detail.

It looks sane to return "server-provided" casing, and allow for case insensitive access, doesn't it?

ResultSet.getInt(String) allows for case-insensitive access.

@vlsi, I am good with the getParamterStatus(String) method being case insensitive to the parameter. I am a bit conflicted on returning a Map with all values and making any statement on it providing a case insensitive get.

@bokken 👍
I'm inclining to a map with properties of:

1. "server-native" casing
2. "forbidden modifications"
3. "might become out of date"

WHYT?

@vlsi, I think my preference would still be to return a collection of parameter names (with properties you list) to get the available names. But I am fine with the map you describe.

We got rid of forbidden modifications. And I really fail to see the point of the rest, it seems excessively complex.

I take your point about keySet() returning the server-provided cases. But I don't really see the problem with it. The case won't tend to vary as the server doesn't change the case it uses, and the keys will get the correct parameters when looked up. The only possible issue I see is someReturnedKey.equals("APPLICATION_NAME") not matching ... and that's no different to how the system already behaves with a query of pg_settings.

Why is it a TreeMap?
Should the field be just Map and the value just HashMap?

TreeMap is used to permit String.CASE_INSENSITIVE_ORDER, which is not supported by HashMap. That ensures that parameter lookups will find the parameter no matter what case is used - datestyle or DateStyle for example.

Pg's parameters use a mix of camel case and underscore separators. Users generally expect case-folding behaviour in postgres, too. So I'd strongly prefer to do this.

What does Keys are case-insensitive mean?
Does backend send the same parameter with multiple casing variations?

Applications may use parameters in any combination of letter cases and expect the same result. So the PgJDBC interface should be consistent with that, otherwise users will experience unexpected results if they

stmt.execute("SET Application_Name = 'ILoveCamelCase';");
// then in a more sensible part of the application
pgconn.getParameterStatus("application_name");

Observe

SET APPLICATION_NAME='myapp';
SHOW aPpLiCaTiON_name;
SHOW application_name;

As Java provides a trivial way to make map keys case-insensitive and case-preserving it makes sense to do so.

I guess the naming implies the method would send the parameter status to the database, while the actual meaning is the other way around.
onParameterStatus might be better.

Good point, Java accessor convention. Will do.

do we have any potential concurrency issue here?
IIRC, query executors are used/reused for life of connection, which can get used across threads (particularly when connections pooled). Here we are potentially mutating the map on different threads from where it is being accessed/read and giving a live "view" of the map on the read method.

@bokken At any point where onParameterStatus may be called, the current thread holds the monitor of the object guarding the entrypoint. We can only get parameter status messages during query result processing or when processing notices by explicit user request in processNotifies(). The latter is synchronized on QueryExecutorImpl, and all the querying entry points also take the QueryExecutorImpl monitor. They have to, otherwise we'd have a horrible mess on our hands already.

No query executor can be used for more than one connection, and no connection may run more than one statement at a time or process results from more than one statement.

You could annotate it synchronized but that'd be (a) unnecessary and (b) if it was necessary, wrong and likely to cause deadlocks.

@ringerc, my concern was not necessarily concurrent threads calling onParamterStatus, but rather consistency between reading from the map on a different thread from where it was mutated.