Did you check to make sure the plan is the same as previously ?

@davecramer I assume the plan would be different, because I verified that the change drastically improved the performance of getCrossReference. With the same arguments and environment, version 42.7.5 took 3835 ms and the new version took 1504 ms.

@SophiahHo thanks!

@SophiahHo reviewing this as I understand this you are adding and FALSE if the catalog isn't equal to the current catalog. Why even run the SQL? We know the ResultSet is going to be empty, we could fabricate an empty ResultSet instead.

@davecramer Fabricating an empty ResultSet would be pages and pages long. Additionally, returning an empty ResultSet would be incorrect behaviour if the database is down, the database user credentials were revoked or changed, etc., which should throw an Exception.

I think it should be uncommon for the client code to ask for a list of "procedures in a foreign catalog", so it should be fine to go with and false trick.
At the same time, certain cases make it easy to return empty resultset without making a database roundtrip.

@SophiahHo , in some of the cases, we use org.postgresql.core.BaseStatement#createDriverResultSet(Field[] fields, List<Tuple> tuples) can create resultset. For instance, getProcedureColumns prepares Field[] declaration, and then it executes a query.
In that case we could use something like

if (catalog != null && !catalog.equals(...)) {
  // Returns empty resultset
  ((BaseStatement) createMetaDataStatement()).createDriverResultSet(f, v)
}

I guess Dave meant something like that. WDYT?

@vlsi I already merged #3588

Does it mean we should close the current PR then?

Does it mean we should close the current PR then?

Yes, I would think so.

Closed in favour of #3588