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

feat: support connecting to different databases #121

Merged
merged 3 commits into from
Apr 29, 2022

Conversation

olavloite
Copy link
Collaborator

Support connecting to different databases on an instance. This allows
for the use of the \c command in psql, as well as using a single
instance of PGAdapter to connect to multiple different databases using
other clients. The -d command line parameter is still supported, but
is now interpreted as follows:

  1. If omitted, PGAdapter will connect to the database given in the
    connection request.
  2. If included, PGAdapter will always connect to the database given in
    the -d command line parameter and ignore the database in the
    connection request.

Fixes b/194320320

Support connecting to different databases on an instance. This allows
for the use of the `\c` command in psql, as well as using a single
instance of PGAdapter to connect to multiple different databases using
other clients. The `-d` command line parameter is still supported, but
is now interpreted as follows:
1. If omitted, PGAdapter will connect to the database given in the
   connection request.
2. If included, PGAdapter will always connect to the database given in
   the -d command line parameter and ignore the database in the
   connection request.

Fixes b/194320320
@aseering
Copy link

Do I understand correctly that this is a "breaking change" in the sense that, if customers relied on PGAdapter's behavior of ignoring the database specified by psql (which is pretty easy to do, for example with scripts that assume they can connect to the postgres default database to do admin operations), previously they might have worked and now they won't?

If so, could this be accompanied by a bump to PGAdapter's published major version? That would be a minimal way to signal a breaking change.

@olavloite
Copy link
Collaborator Author

olavloite commented Apr 20, 2022

Do I understand correctly that this is a "breaking change" in the sense that, if customers relied on PGAdapter's behavior of ignoring the database specified by psql (which is pretty easy to do, for example with scripts that assume they can connect to the postgres default database to do admin operations), previously they might have worked and now they won't?

If so, could this be accompanied by a bump to PGAdapter's published major version? That would be a minimal way to signal a breaking change.

No, I think either my comment was not clear enough or you did not read that correctly :-)

The behavior is:

  1. If you continue to start PGAdapter with the -d command: The behavior remains exactly as it is now. The database name in the connection request is always ignored.
  2. If you omit the -d command: PGAdapter will always use the database name in the connection request.

Note that the -d command was required. This PR changes that and makes it optional. So there is currently no one who can be using PGAdapter without the -d command.

@aseering
Copy link

Ah, I see: In your original statement, when reading:

If included, PGAdapter will always connect to the database given in
the -d command line parameter and ignore the database in the
connection request.

I interpreted that as the -d argument to psql. I think you actually meant the -d argument to PGAdapter? Which in retrospect should have been evident from context; I just mis-parsed.

Anyway, agreed, SGTM.

@olavloite olavloite merged commit 2bc0355 into postgresql-dialect Apr 29, 2022
@olavloite olavloite deleted the support-slash-c branch April 29, 2022 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants