doltgres 0.5.0

[BrewTestBot]

Created by brew bump

---

Created with brew bump-formula-pr.

release notes

# Merged PRs
doltgresql

152: support AGGREGATE statement syntaxes

This PR adds support for CREATE AGGREGATE and DROP AGGREGATE statements syntaxes.
151: /{go.mod,.github}: bump go version
150: support TYPE and DOMAIN statements syntaxes

This PR adds support for CREATE TYPE, ALTER TYPE, CREATE DOMAIN, ALTER DOMAIN AND DROP DOMAIN statement syntaxes.
149: support LANGUAGE syntaxes

This PR adds support for CREATE, ALTER and DROP LANGUAGE statements syntaxes.
148: Replication options for config.yaml

Also fixed an issue where the --config option wasn't working (looking in the wrong directory).
147: Added unary and binary operator functions

This adds all of the internal functions for unary and binary operators (for types that are currently implemented).
145: support all SEQUENCE statements syntax

This PR adds complete support for parsing SEQUENCE syntaxes.
144: INT4 ORDER BY Workaround

There are two bugs here. The first is that INTEGER and INT were parsing as INT8. The second is that ORDER BY 1 was failing for tables that had an INT4 but not an INT8. For the first, our parser simply used the wrong bit width, which is fairly straightforward.

The second bug was far trickier to track down. Essentially, ORDER BY 1 has been broken, however some combinations of tables and rows would result in the correct order on accident, and that's what led to the confusion on how the second bug worked. It's even more coincidental that the literal 1 in ORDER BY 1 happened to correspond to the first value in the affected tests, further masking the issue.

Fundamentally, the issue has not been fixed, and this submits a workaround. The root of the issue is that GMS expects the vitess.SQLVal type, and does not handle our case (Postgres literals). As a workaround, we're converting our Postgres literals to vitess.SQLVal specifically for this exact case. The real fix would be for GMS to defer to Doltgres when encountering types that it cannot hardcode (or to un-hardcode types, which seems relatively bad for GMS just to work better with Doltgres). We do not have a standard way of implementing this differing interface yet, so we'll punt on that and just get this workaround in.
143: Support configuration parameters handling

This PR includes changes for:

The complete list of configuration parameters is in.
All of the postgres configuration parameters will be added to existing system variables list in GMS. There are two parameters that have the same name as mysql system variables, which will be overwritten by the postgres parameter. This is temporary until we completely separate the use of them.
Current implementation of sql.SystemVariableRegistry interface is for Dolt only, but we add all the postgres configuration parameters to the SystemVariables global variable in GMS. This should be updated to handle Doltgres config parameters separately in future.
The default and only supported scope of postgres parameters is SESSION, which is used as SESSION scope in GMS. There is no GLOBAL scope in postgres to be set during a session.

Depends on GMS PR: create system variable interface dolthub/go-mysql-server#2375

Depends on Dolt PR: use system variable interface dolthub/dolt#7579

Next up:
need more support for Parameter such as accept setting memory and time values that has unit information, etc.
need privileges and role checking for specific parameters.
support setting parameter defaults from configuration file.
`LOCAL scope support.


142: Added a plethora of function tests

This adds tests for most of the functions, along with the generation code that grabs results from a running PostgreSQL 15 to create tests with.
141: added nil check in Addition expression

new Addition expression can be used without children expressions defined

Note: majority of the tests regressed because of not being able to check doltgres-specific types in GMS.

E.g: doltgres types.Int64Type is not recognized as NumberTypeImpl_ in GMS.


140: Tests and fixes for more replication scenarios
139: add TRIGGER statements parsing

Adds syntax parsing support for:

CREATE TRIGGER
ALTER TRIGGER
DROP TRIGGER


138: add VIEW and MATERIALIZED VIEW statements parsing

Adds syntax parsing support for:

CREATE VIEW
CREATE MATERIALIZED VIEW
ALTER VIEW
ALTER MATERIALIZED VIEW


137: More replication tests

Tests discovered and fixed several issues from first draft, mostly involving stopping and resuming replication and many races in testing and the replicator itself.

Next step: error handling tests using toxiproxy

Final step: UX and docs
136: support PROCEDURE statements syntax parsing

This PR includes syntax parsing support for:

CREATE PROCEDURE
DROP PROCEDURE
ALTER PROCEDURE
ALTER FUNCTION


135: support parsing ALTER INDEX stmt

This PR also fixes all the synopsis that had [ $argmode$ ] [ $argname$ ] $argtype$ [ , ... ] to correct format of { [ $argmode$ ] [ $argname$ ] $argtype$ } [ , ... ]. The tests that are affected by this change is updated.
134: Update update-perf.sh
133: Function Overload Rework

What this adds:

Type resolution for all extended (Doltgres) types
Proper type casting between types (extendable to support user-defined conversion)
Additional Types

The previous function overload framework only worked in a very limited capacity. This PR intends to remove those limitations, allowing for all current (and future) Postgres functions to be defined. In general, this is also designed to support user-defined functionality, or at least designed in such a way that it will be relatively easy to fully implement it later on.

Related PR: Fixed handler bug related to ExtendedTypes dolthub/dolt#7537


132: New test runner

Test runner for docker-based replication tests
131: Docker test for postgres replication

Seeking some feedback on this approach. This works locally for me on my local Docker when I build the image from the package root:
docker build --file=testing/ReplicationTestDockerfile .
Next step would be to create a github action that runs this docker file and a workflow trigger for that action. Is this going to work? I looked into the examples in the Dolt repo and got confused by the paths that github actions appears to use at execution time, so could use some advice on best practices.
130: support for parsing CREATE TABLE and ALTER TABLE statement syntax

This PR adds support for parsing CREATE TABLE and ALTER TABLE statements

It also removes some parsing code for statements that are not supported in Postgres.
129: replication POC and tests

Looking for feedback on this approach before polishing it off for submission.

Missing / next steps:

Keyless table tests
Start up postgres during CI so the replication tests can run correctly there
UX to configure and start up replication for the server


128: [auto-update-readme] by coffeegoddd
127: [auto-update-readme] by coffeegoddd
126: Release v0.4.0

Created by the Release workflow to update DoltgreSQL's version

Closed Issues

146: someone is trolling doltgresql stars and sending unsollicited emails

[chenrui333]

reapply the test update from #167420

[github-actions]

@chenrui333 has requested bottles to be published to this PR.