pgx v4 -> v5

[eldang]

After #246 I realised that https://nvd.nist.gov/vuln/detail/CVE-2026-32286 was still being flagged. It turns out there's no plan to fix that vulnerability in the older versions of pgproto3 because that module has since been rolled into pgx v5, and the maintainers understandably only want to maintain the current version. But the major version increment dropped a couple of structures that pg_tileserv was using. This PR is my attempt at replacing that functionality.

It's my first time making non-trivial changes to internal code for this tool, so I think it is worth more careful review than my usual minor dependency version updates. I will try to flag everything I have any uncertainty about....

Testing I've done so far:

• Builds without errors
• Passes go lint and go vet without any complaints
• go test -v
• Actually using the tile server for real in a project

[eldang]

To be honest this is the change I'm most unhappy about. I haven't been able to figure out how to use logrus with pgx v5. Removing this code entirely is working fine for my purposes, but I'm guessing there are log levels at which it may prevent us from getting the intended level of output.

[eldang]

pgconn and pgtype have been moved into pgx for v5.

[eldang]

pgtype v5 has switched the definition of Float8 (the type of each number in the bounding box) to:

type Float8 struct {
	Float64 float64
	Valid   bool
}

So I made two corresponding changes:

• Getting the values out as .Float64 (above)
• In the absence of a Status property, taking a guess that I could get the same result by checking for .Valid. I'm not certain of how fully equivalent this is, but it seems to be working the same.

[eldang]

I'm assuming, without having had a way of testing this directly, that without an explicit TextArray.Status I can rely on simply checking if there's anything in the array.

[eldang]

It looks like the old version of pgtype figured out the length of individual elements while unmarshalling JSON to the text array. I couldn't figure out a good way to do that, so I've hard-coded it as 4 on the assumption that the SQL which generates the JSON:

		(
			SELECT array_agg(ARRAY[sa.attname, st.typname, coalesce(da.description,''), sa.attnum::text]::text[] ORDER BY sa.attnum)
			FROM pg_attribute sa
			JOIN pg_type st ON sa.atttypid = st.oid
			LEFT JOIN pg_description da ON (c.oid = da.objoid and sa.attnum = da.objsubid)
			WHERE sa.attrelid = c.oid
			AND sa.attnum > 0
			AND NOT sa.attisdropped
			AND st.typname NOT IN ('geometry', 'geography')
		) AS props

can only ever make arrays in which the inner element always has 4 items. In doing this, I take some comfort from the hard-coded 1, 2, 3 offsets in the next few lines (to find the type, description, and ordering). But if my assumption is ever wrong, it is likely to be a crashing bug.

[eldang]

Update to this comment: I realised late that I could actually make a 2-dimensional array of pgtype.Text values, which let me simplify the code a bit, and at least won't crash if we ever get > 4 elements inside a props value.

[eldang]

This was simply to silence a go vet warning. It didn't like that an exported function returns an unexported type. When I realised that the function is only ever called within this file, I figured simply making the function unexported would be a safe way to address that.

[eldang]

Unfortunately I can't see what the failing tests are. If the content of them is stuff I could potentially address, just let me know.

[eldang]

This is where I'm really out of my comfort zone. pgtype v5 doesn't have a TextArray type at all, and it looks like that type used to do some automated array dimensions calculations for us. So I've had to replace the functionality that used to be provided by the Status and Dimensions members of TextArray, while replacing the actual text array member directly.