Merged PRs

doltgresql

• 2503: Fixed DST handling by moving to timeofday time.Time serialization and deserialization can cause information to be irreversibly lost due to daylight savings time changes. The location isn't directly serialized due to it being tied to the runtime system information (different operating systems may have different time zone information), and is therefore reconstructed on deserialization. This is fine for timestamptz, as we internally process everything as UTC and use the client's timezone when returning values to the client. For timetz, however, the timezone information is embedded in the value itself and is independent of the client, and this was causing information loss during serialization. This PR changes serialization to use the timetz.TimeTZ type, which is already used at most steps (by casting time.Time to timetz.TimeTZ and vice-versa), and therefore the change propagates to all functions that take a timetz value. In line with this, the time type was updated to use timeofday.TimeOfDay, which is also already used internally in most functions. Although serialization is fine, this was changed to be more inline with timetz (as timetz.TimeTZ directly uses timeofday.TimeOfDay) and also due to time.Time carrying implicit information that can cause direct value comparisons to be incorrect. For example, '01:00:00'::time should sort before '02:00:00'::time, however adding 24 hours to the first value will still result in the correct hour mark for display, but internally the time.Time value would be on the next day, and would cause the comparison to actually show '02:00:00'::time appearing first (assuming they started on the same day to begin with). All of these issues are fixed by using the correct types that are already in Doltgres, and already used by the internal functions. I'm not sure why we decided to use time.Time instead of those anyway (as interval uses the internal type rather than casting to time.Duration), but this fixes it. This does mean that the serialization is incompatible with existing databases, however since serialization was incorrect in the first place, it's a necessary change.
• 2496: /.github/workflows: bump actions checkout
• 2494: add is distinct and not distinct from exprs
• 2490: resolve user defined type in drop routine
• 2487: Added proper support for receiving binary formatted values This is the receive counterpart to the following PR:
• https://github.com/dolthub/doltgresql/pull/2394 All new tests were validated against a live Postgres 15 server to ensure that we're processing client input properly. In addition, I've added a little more testing on the send side as well, as there were a couple of small gaps in coverage.
• 2478: remove ValidateTagUniqueness companion pr: https://github.com/dolthub/dolt/pull/10707
• 2476: Misc Fixes for Prisma 3 things in this PR:
• Makes version numbers consistent. I used 15.17 which is the latest version of postgresql 15.
• Make the col_description, obj_description, and shobj_description return the correct value for "no comments", rather than "empty comments". They are still no-op functions but now return NULL instead of empty strings. More detailed information on these functions can be found here
• generate_subscripts is a set returning function that returns the indices of the array you give it. So for instance the array [10, 40, 23] will return {1, 2, 3}. Most postgresql array types are 1-indexed, except for the types oidvector and int2vector. I added a fix so that generate_subscripts respects those two's unique indexing. More on generate_subscripts here. oidvector and int2vector don't seem to have standard docs pages but this site provides basic details.
• 2472: add fors plpgsql statement
• 2464: Support creating/dropping DB with hypens in name Adds functionality and testing for creating databases like test-db. Currently: create database "test-db" will create a database called "test-db" (with the escaped quotes). drop database "test-db" will try to look for a database called "test-db" to drop (with the escaped quotes).
• 2458: Moved the binary wire format for receiving to the receive func
• 2454: resolve type with database provided
• 2447: support fori plpgsql statement

Closed Issues

• 2333: UPDATE SET date_column = '2026-02-14' fails without explicit ::date cast via simple protocol