Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PostgresTypes returns types that aren't visible in the current schema #357

Open
osi opened this issue Nov 24, 2020 · 9 comments
Open

PostgresTypes returns types that aren't visible in the current schema #357

osi opened this issue Nov 24, 2020 · 9 comments
Labels
status: ideal-for-contribution An issue that a contributor can help us with type: task A general task

Comments

@osi
Copy link

osi commented Nov 24, 2020

  • Driver: 0.8.6

PostgresTypes does a LEFT JOIN against the namespaces, resulting in multiple types being returned if the type is defined in multiple namespaces

+ " LEFT "
+ " JOIN (select ns.oid as nspoid, ns.nspname, r.r "

I have a type that is defined in multiple schemas (the schema is a "version", and application code is only using a specific version). This is controlled by the active schema, and current_schemas will only return a single one. If I have a type defined in 3 schemas, I will receive three results from PostgresTypes as it does a LEFT JOIN against the visible namespaces rather than an INNER JOIN.

If the LEFT JOIN behavior is desired, adding the namespace to the returned object would allow filtering in application code.

@osi osi added the status: waiting-for-triage An issue we've not yet triaged label Nov 24, 2020
@mp911de
Copy link
Collaborator

mp911de commented Nov 24, 2020

We should be doing what PGJDBC does. /cc @davecramer

@osi
Copy link
Author

osi commented Nov 24, 2020

PGJDBC only keeps the first match for a name,

https://github.com/pgjdbc/pgjdbc/blob/51f18bf7755b97a4ab3e560431a3578d119a2bdf/pgjdbc/src/main/java/org/postgresql/jdbc/TypeInfoCache.java#L202-L206

https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/jdbc/TypeInfoCache.java#L265-L267

.. I was naively assuming (looking at the API surface) that I'd only get a single result for a name out of lookupTypes. I can think of the following ways to address this:

  • Solve via documentation that duplicates will be returned, and that duplicates will be ordered based on the order of the schema in the search path
  • The above, but also providing the containing schema name on io.r2dbc.postgresql.codec.PostgresTypes.PostgresType, so users would know the containing schema to pick their match
  • Have lookupTypes only return the first match for a given name (similar to how lookupType will only return one match)

@osi
Copy link
Author

osi commented Nov 24, 2020

Also, if using the provided EnumCodec with a registration priority of FIRST will result in an enum that's present in multiple schemas to have the one from the end of the search path as the first choice (which seems undesirable)

@davecramer
Copy link
Member

@osi Since it is actually possible to have a valid type with the same name in two different active schemas it seems to me that we need to return a schema qualified type.

Thoughts?

@osi
Copy link
Author

osi commented Dec 8, 2020

@davecramer that'd be the least ambiguous option when there are multiple active schemas. (that's actually how I discovered this problem, when the server gave me an error with the schema-qualified name that it was seeing vs expected)

@davecramer
Copy link
Member

@osi OK, I'll take a run at implementing that, unless you have some cycles ?

@osi
Copy link
Author

osi commented Dec 8, 2020

I'l have cycles by end-of-year, if that timeframe works.

@davecramer
Copy link
Member

if it's still around by then, have at it.

@mp911de mp911de added status: ideal-for-contribution An issue that a contributor can help us with type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 14, 2020
@osi
Copy link
Author

osi commented Dec 22, 2020

I went to work on this and realized it isn't a problem with enums. My initial observation was with a custom type, and I was using CodecRegistry#addFirst instead of CodecRegistry#addLast, so the types that appeared later in the schema search path were given greater priority in the registry, leading to their use.

If anything I'd say we could do this,

Solve via documentation that duplicates will be returned, and that duplicates will be ordered based on the order of the schema in the search path

.. using addFirst is likely not what is desired when adding additional type mappings. In my code, i was using addFirst as I have a couple of codec's that I want to run before some of the built-ins (to create custom value types in my domain).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ideal-for-contribution An issue that a contributor can help us with type: task A general task
Projects
None yet
Development

No branches or pull requests

3 participants