feat: Update migrations postgres URI parsing and add tests

[fbis251]

This PR updates the parsing and formatting of the URI that is used when applying migrations and adds tests for sample input connStrings

As of 94d7d68, using a connString with a non-default port number will ignore the custom port and default to 5432 in PgBackend.initializeDB when attempting to run migrations. The current connString formatting code will read pgxCfg.Host but not pgxCfg.Port when generating the new connString

• postgresq://localhost:5433/neoq?sslmode=disable - Example input connString
• postgresq://localhost/neoq?sslmode=disable&x-migrations-table=neoq_schema_migrations - connString that is actually used by PgBackend to try to apply migrations, note the default 5432 port number will be used since it's not specified

neoq/backends/postgres/postgres_backend.go

Lines 356 to 361 in 94d7d68

	pqConnectionString := fmt.Sprintf("postgres://%s:%s@%s/%s?sslmode=%s&x-migrations-table=neoq_schema_migrations",
	pgxCfg.User,
	url.QueryEscape(pgxCfg.Password),
	pgxCfg.Host,
	pgxCfg.Database,
	sslMode)

Note that pq-style URLs are not supported, please let me know if you would like support for them

[fbis251]

@acaloiaro pq-style strings are expected to cause an error with the current implementation in my PR. Please let me know if you'd like me to add support for them

[acaloiaro]

I would prefer pq-style connection strings to be supported if it's not too much trouble.

[fbis251]

hi @acaloiaro I apologize about the delay, I just pushed up commit c5d1bfc which adds support for pq-style strings.

The input string will still go through pgx.ParseConfig which will make sure it was in a valid format before it's returned unmodified.

Let me know what you think

[acaloiaro]

@fbis251 This looks great, and thank you for the contribution.

I'd prefer not to regress support for libpq compatiable connection strings (https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING)

But with that said, I also don't personally use them, and I don't find them to be terribly common in other projects. So I'm not a huge advocate for them, I'd just prefer not to regress support.

If we do allow support to regress, we'll want to flag the commit with break: ... so that the releaser adds it to the changelog as a breaking change. We'll also want to update any docs related to connection strings. I recall mentioning the two formats somewhere.

[acaloiaro]

I would prefer pq-style connection strings to be supported if it's not too much trouble.

[acaloiaro]

Hi @fbis251 -- are you still interested in moving this PR forward?

[acaloiaro]

This looks good!

Now that it's ready, could you squash it down to a single commit and prefix the commit message with feat:?

e.g. feat: Improve Postgres URI parsing

This helps build the changelog.

[fbis251]

@acaloiaro I squashed, rebased against main, and updated the PR title to add the feat: prefix

[acaloiaro]

@fbis251 shippin' dreams, thanks again.