0.8.0

Merged PRs

doltgresql

• 336: Added string literal to array interpretation
  This adds functionality so that string literals such as '{1,2,3}' can be interpreted as arrays of any type. This builds off of the #333 PR, which enables this to "just work" for all contexts (includes casting, inserting into columns, automatic operator resolution, etc.). This also includes additional tests for a few bugs that weren't caught in the previous PR.
• 333: Removed sql.Convert usage, moved everything to casts
  This removes our reliance on sql.Convert and changed everything to make use of casts. Casts have three contexts: explicit (value::type), assignment (INSERT and UPDATE statements), and implicit. In addition to moving to casts, I've also added assignment casts.
  This move also comes with a massive change to how function overloads are handled. Overload resolution is handled through available casts, so by removing the hacky behavior that was in place, we're now able to unskip a number of tests that just could not be handled through the previous logic. There were other tests that were also incorrect, and those have been fixed.
  Overall, this has resulted in a fairly substantial decrease in code throughout the codebase, in addition to allowing for types to finally have "full" support.
  Companion PR:
  • dolthub/go-mysql-server#2523
• 325: Update get-doltgres-correctness-job-json.sh
• 320: Update schema path in scripts
• 319: Added comparisons for JSONB
  This adds comparisons for jsonb. In the original JSON PR, I mistakenly only checked if json had comparisons, and that type does not. jsonb, however, does have comparisons, so this implements those. In addition, I've added a massive collection of rows that it properly sorts over. Test results were lifted straight from a Postgres 15 server to ensure accuracy.
• 317: /utils/doltgres_builder/run.go: fix doltgres builder paths
• 302: Added JSON types
  This adds JSON types, and also fixes a bug where the text types would incorrectly persist an empty string as a NULL.
• 288: Release v0.7.5
  Created by the Release workflow to update DoltgreSQL's version
• 287: Added SERIAL types along with remaining SEQUENCE functionality
  Companion PRs:
  • dolthub/vitess#347
  • dolthub/go-mysql-server#2504
    This adds the SERIAL types, along with the remaining functionality for sequences that was not present in the first PR. In addition, this adds our first uses of injected analyzer steps, and introduces custom nodes used for the sequence statements (instead of stored procedures).
• 269: New tests for schema support
  Also changes expected errors to match an error string. Not all tests are passing yet.
• 185: Update README.md

Closed Issues

• 280: Release 0.7.4 for windows not Working
• 90: doltgres version shows the previous version
• 279: Doltgresql does not yet support PostgreSQL's JDBC connection

0.7.5

Merged PRs

doltgresql

• 283: scripts/build_binaries.sh: Fix regression where we accidentally shipped all linux/amd64 binaries instead of platform-specific ones.
• 276: move config to its own package and update dolt servercfg package
• 273: EXECUTE doesn't send RowDescription
  This PR fixes issue connecting to doltgres server using Postgres JDBC driver.
  In Postgres docs, it says, "Execute doesn't cause ReadyForQuery or RowDescription to be issued."
  Also, queries that don't return set of rows send NoData in response to Describe message.
• 266: Release v0.7.4
  Created by the Release workflow to update DoltgreSQL's version
• 255: only some queries send RowDescription message
  • Only queries that returns set of rows should send RowDescription message. This includes SELECT, FETCH, SHOW, etc.
  • The CommandTag is now set by the StatementTag from the parsed query.
  • Empty query should send EmptyQueryResponse message.
• 219: Adds CREATE SEQUENCE and DROP SEQUENCE
  Companion PR:
  • dolthub/dolt#7848
    This adds functionality for CREATE SEQUENCE and DROP SEQUENCE. For sequences, this is what is in the PR:
  • MINVALUE
  • MAXVALUE
  • INCREMENT
  • AS DATA TYPE
  • START WITH
  • CYCLE
    This is what is missing:
  • TEMPORARY
  • UNLOGGED
  • CACHE
  • OWNED BY
  • SERIAL
  • Merging
  • Table Querying
    Of what's missing, merging and SERIAL are the main additions, with OWNED BY required for proper SERIAL support. Table querying is fairly straightforward (the pg_sequences system table, etc.). The others are, hopefully, unnecessary for now and can be postponed, although perhaps we can save the CACHE value and ignore it since it's primarily a performance-oriented option.
    With that, SERIAL and merging will come in the next PR, since this is already very large. Also of note, the Writer and Reader utilities were implemented for my Convert-to-Cast PR but they were useful here, so I pulled them from that in-flight PR and added them here.

Closed Issues

• 240: Returned result differs from Postgres

0.7.4

Merged PRs

doltgresql

• 263: add server/config.go to the release commit

Closed Issues

0.7.1

Merged PRs

doltgresql

• 261: add the minver_validation.txt file to the release commit
  Does the same thing as: https://github.com/dolthub/dolt/blob/main/.github/workflows/cd-release-pgo.yaml#L79
• 260: Release v0.7.0
  Created by the Release workflow to update DoltgreSQL's version

Closed Issues

0.7.0

Merged PRs

doltgresql

• 259: build parser earlier in release process
  The parser needs to be built before go run -mod=readonly ./utils/genminver_validation/ $FILE
• 258: bump go version to 1.22.1
• 253: /.github/workflows/bump-dependency.yaml: use personal tokens to open prs to ensure ci runs
• 245: Fixes LIMIT
  Fixes #172
• 244: Fixed replication tests
• 232: Added Doltgres-implementation of RootValue
  Companion:
  • dolthub/dolt#7829
    This is Doltgres' implementation of RootValue. For now, it's essentially taken wholesale from Dolt as a starting point. Of note, we probably want to at least get something different for our collation values sometime soon. Also, we're using the same serial identifier for root values between Doltgres and Dolt. This simplifies a good bit of code in Dolt, so taking on the naming requirement seems well worth it.
• 231: kill subcommands
• 226: Add better cast tests for name, fix bool -> name cast
• 221: move main
  Move the main package to cmd/doltgres so that the source built binary matches the released binary.
• 214: scripts/build_binaries.sh: Build releases with CGO enabled.
• 210: Implement xid type
• 204: Implement oid type
• 202: Implement name type
• 191: Fix typo and go test command in docs
• 188: Added website and documentation site to README
• 184: /.github/markdown-templates/dep-bump.md: add md template
• 183: use personal token so release pr runs CI
• 182: Added explicit initialization order to packages
  This replaces all of the init() functions throughout the project with a package-level Init() function that is called from a new initialization package. This now gives an explicit ordering to the calls. The biggest disadvantage of this approach is that some packages cannot have package-level tests that can access package-private variables without potentially causing import cycles if they need to initialize another package. This was also a limitation with the previous init() approach as well, but the vast majority of our tests are done from the testing subdirectories (in part due to this limitation), so we've not lost anything by changing to this approach.
• 181: Support for schemas
  Things that work:
  • Create schema
  • Explicit schema name qualifiers in statements, with and without database name qualifiers
    Things that don't work:
  • Foreign keys
  • Search path support for resolving table names
  • Automatically creating a public schema for new databases
  • Revision name qualifiers (branch name DBs)
• 180: Update bump-dependency.yaml
• 179: Update bump-dependency.yaml
• 178: Revert "/.github/workflows/cd-release.yaml: revert bump of dolthub actions"
  Reverts #176 as these actions have been updated and work now
• 177: Release v0.6.0
  Created by the Release workflow to update DoltgreSQL's version
• 168: support CREATE VIEW
  Depends on:
  • dolthub/vitess#332
  • dolthub/go-mysql-server#2448
  • dolthub/go-mysql-server#2486
  • dolthub/dolt#7819

Closed Issues

• 172: The LIMIT expression is not working

0.6.0

Merged PRs

doltgresql

• 176: /.github/workflows/cd-release.yaml: revert bump of dolthub actions
• 174: Db/bump actions
• 169: doltgresql version --dolt
• 167: Added more types, reworked cast framework
  This adds several new types, and also reworks type serialization and casting, among a few other things. This is not nearly as tested as I'd want it to be, as I discovered that the implicit/explicit casting is fundamentally incompatible with how we use sql.Type.Convert, so that entire system needs to be "removed" for Doltgres (that is, it functionally should not do anything).
  In addition, in an effort to be a little forward-thinking since I'm assuming we'll be breaking things a bit once the conversion system is removed, I added a form of type versions so that we can update types as we discover deficiencies. For example, let's say a type uses -1 to mean "no limit", and then we later find out that -1 is a valid value. We can make that distinction using type versions. In addition, this will break all existing databases due to the type serialization change, but I think it's fine as all currently known users should be able to rebuild the database since their replicas.
• 166: add parsing support for OUT and INOUT argmode for routines
  Aggregate only allows IN and VARIADIC argument modes. Routines including functions and procedures allows IN, VARIADIC, OUT and INOUT modes. The parser will allow OUT and INOUT for aggregates, so TODO there needs a check during ast evaluation/conversion for these modes in aggregate statements.
  • small fix for supporting SETOF modifier option for CREATE FUNCTION statement.
  • small fix for supporting db.aggregate_name syntax for AGGREGATE statements.
• 165: Removed inline VarChar implementation
  This removes the inline VarChar variable. It's not used anywhere, so it's best to remove it before we use it in a location that we don't mean to. We still retain the inline characteristics for user-defined columns that define a limit below the inline max though.
• 164: Reworked array serialization format
  This is building off of the following PR comment:
  #162 (comment)
  In Postgres, there seems to be a field size limit of 1GB, so I've used that to determine that we can just use uint32s everywhere, rather than having two formats with uint16 and uint64 (which were attempts at conserving space).
• 163: use auto_increment for SERIAL type
  This PR reverts the latest change on using auto_increment for SERIAL type column definition.
  Note: INSERT on SERIAL type as primary key does not work for now.
• 162: All Array Types
  This PR adds array types for all existing types. This is done by providing a wrapper that handles all of the array-functionality over the base type. In addition, this removes the mock array functionality that only worked to demonstrate the viability of boolean[], replacing the functionality with fully working equivalents.
• 161: remove usage of auto_increment for SERIAL type for column definition
• 159: small fix for SET syntax accepting multiple values as a single value
• 158: support COMMENT statement syntax
• 157: Release v0.5.0
  Created by the Release workflow to update DoltgreSQL's version
• 156: Use go 1.22 for release process
• 152: support AGGREGATE statement syntaxes
  This PR adds support for CREATE AGGREGATE and DROP AGGREGATE statements syntaxes.

Closed Issues

0.5.0

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: dolthub/go-mysql-server#2375
    Depends on Dolt PR: 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: 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:
  1. Keyless table tests
  2. Start up postgres during CI so the replication tests can run correctly there
  3. 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

0.4.0

Merged PRs

doltgresql

• 125: Added UUID type
  This adds the UUID type. Ignore the serialization portion for now, I'll figure out a different serialization scheme later that should work for all types (including user-defined types). While this works, we need to forward the type information through to the connector so it can use the correct OID. For now though, this should be enough to unblock.
• 123: Fixed command docs generation
  Sometimes, command docs would generate duplicate tests. This was due to the RNG selecting the same number multiple times. This fixes this issue, along with fixing all of the affected tests. There are still duplicate tests, but that is due to the synopses defining the duplicates, rather than the generation, which I think is fine.
• 122: support syntax parsing for INDEX statements
  This PR adds syntax parsing support for:
  • CREATE INDEX
  • CREATE TABLE AS
    It also splits postgres/parser/sem/tree/create.go file into create_*.go files for each specific statements.
• 121: Referencing columns within arrays
  This makes use of an addition to Vitess and GMS that allows for name resolution to occur for injected expressions. The new ARRAY[...] smoke test demonstrates this.
  Related PRs:
  • dolthub/vitess#312
  • dolthub/go-mysql-server#2322
• 120: Added BOOLEAN and BOOLEAN[] types
  This adds rough support for both BOOLEAN and BOOLEAN[] types. This is primarily to show a working implementation of the new ExtendedType interface that was added to GMS to support these new types, demonstrating that we can now add standard PostgreSQL types, as well as array types (along with accompanying functionality, such as ARRAY[] support).
  Related PRs:
  • dolthub/vitess#309
  • dolthub/go-mysql-server#2312
  • dolthub/dolt#7457
• 119: support parsing create extension and function statements
  Added parsing support to following statements:
  • CREATE EXTENSION
  • CREATE FUNCTION
  • COMMENT ON EXTENSION
  • DROP EXTENSION
  • DROP FUNCTION
• 118: [auto-update-readme] by coffeegoddd
• 117: [auto-update-readme] by coffeegoddd
• 115: Update get-doltgres-correctness-job-json.sh
• 114: /testing/logictest/harness/doltgres_server_harness.go: catch error
• 113: /README.md: changes for automated perf updates
• 112: /.github/{scripts,workflows}: add script for updating readme, fix other workflows
• 109: /.github/workflows: enable nightly correctness, add latency on pull comment
• 108: /.github/{scripts,workflows}: add correctness workflows
• 107: /.github/scripts/performance-benchmarking/get-{postgres,doltgres}-doltgres-job-json.sh: set email template
• 106: support ddl for schema and database
  This PR adds missing postgres syntax for:
  • CREATE SCHEMA
  • CREATE DATABASE
  • DROP DATABASE
• 105: /.github/workflows: skip tpcc, add nightly benchmarks and benchmarks on release
• 104: /.github/workflows/email-report.yaml: fix email report workflow
• 102: Db/fix ci
• 100: /.github/{actions,scripts,workflows}: add benchmarking workflows to ci
• 99: Better error handling
  Server no longer always forcefully closes a connection when catching a panic, which is still very common because of unsupported features that panic, as well as unintended panics due to bugs.
  This change also refactors the connection handling logic to extract a new ConnectionHandler type.
  Also fixes a problem where a errors during a Query execution would hang a connection while it waited for a Sync message that never came. Added waitForSync flag in ConnectionHandler to manage this bit of state.
• 96: Updated contribution guide
• 95: Better prepared statement support
  Now handles type casts for placeholders, as well as matching a larger variety of expressions.
  Companion PR:
  dolthub/go-mysql-server#2272
• 93: PostgreSQL function PR feedback
• 91: Added more PostgreSQL functions
  This only includes quite a few functions, but doesn't include their tests. I was planning on including those too, but it's turning into a "more work than expected" type of situation, and if I'm going to solve those problems, I'd rather do it with all of the rest of the functions too, so that I can just get all the functions done for all the tests as once. This implements every function that I think we can implement for now based on our currently-supported types (without ripping out the implementation as soon as we get proper type support).
  In the meantime, we can get these functions in, and get the tests in later.
• 89: add utility for building doltgres binaries
• 87: Prepared statement support
  This PR implements postgres prepared statements with support for $1 style parameters in query strings. If this approach is reasonable, the next step would be to add support for additional types and lots more tests.
  Also missing is support for the client manually specifying the types of parameters in a Parse message, which is required for certain statements where the type information cannot be determined based on referenced columns.
  Companion PRs:
  dolthub/go-mysql-server#2239
  dolthub/vitess#299
• 86: support postgres syntaxes - 2
  This PR includes some postgres-specific syntax support.
  • ALTER DATABASE
  • GRANT
  • REVOKE
  • ALTER DEFAULT PRIVILEGES
• 85: support some postgres syntaxes - 1
  This PR includes some postgres-specific syntax support.
  • ABORT
  • ALTER AGGREGATE
  • ALTER COLLATION
  • ALTER CONVERSION
• 84: Release v0.3.1
  Created by the Release workflow to update DoltgreSQL's version
• 83: starting doltgres server creates db in defined directory
  Currently, doltgres uses dolt init when starting doltgres server with data dir set to empty directory. When there is no dolt or doltgres config user.name and user.email, it fails to create a new database with error message from dolt init, which suggests to set dolt user info. Current fix will not return error; instead, it will use user name, postgres and email, [email protected] if it's not set.
• 82: Added a framework for creating PostgreSQL functions
  This is the 2nd version of my attempt at implementing functions.
  The first iteration hijacked *tree.FuncExpr and special-cased names of functions that matched the built-in ones for Postgres. Then it returned a new node that approximated the functionality. In some cases this was as simple as returning a different *vitess.FuncExpr node that pointed to a different function, however some cases did not have direct analogues in MySQL. Originally I was going to ignore those, but since I was working on functions anyway, I decided to tackle them to get it over with, similar to my approach with the entire AST conversion. Well that's when I started running into two key issues:
  1. No straightforward conversion for some functions
  2. Different behavior for similar functions
     The second was born from the first, as I needed to extend my tests to make sure my massive nodes actually worked for most cases. However, extending the tests showed some issues that are somewhat fundamentally different to how MySQL approaches functions, with a big one being overloading.
     The first was a major issue though. I'll post an example in another comment, but some of the nodes became almost unreadable, and they also took forever to create (multiple hours per function, hence the continual delays). The only real maintainable alternative would be to skip the AST conversion pipeline and jump straight to the GMS expressions, but that posed its own issues. Not only is there a lot of boilerplate for expressions, but some of the more sophisticated aspects (such as the origin of values, which I'm calling their Source) are specific to PostgreSQL, So I instead decided to modify the entire set of functions by replacing all of the built-ins (Postgres doesn't want MySQL's built-ins anyway) with a custom "compiled" function structure.
     So now, this mimics a bit how overloaded stored procedures work. We define a set of functions under a single name, and those functions become overloads for that name. Whenev...

0.3.1

Merged PRs

doltgresql

• 83: starting doltgres server creates db in defined directory
  Currently, doltgres uses dolt init when starting doltgres server with data dir set to empty directory. When there is no dolt or doltgres config user.name and user.email, it fails to create a new database with error message from dolt init, which suggests to set dolt user info. Current fix will not return error; instead, it will use user name, postgres and email, [email protected] if it's not set.
• 80: Release v0.3.0
  Created by the Release workflow to update DoltgreSQL's version

Closed Issues

• 81: cannot run doltgres with data dir set to empty directory

0.3.0

Breaking Change

This release changes how directories are handled. Previously, wherever you ran the doltgres binary was where your databases would be located. This was causing a lot of confusion, as attempting to run the doltgres binary from within the doltgres folder (on non-Windows machines) would result in a name conflict, where the program wanted to create a folder named doltgres, but that conflicted with the binary's name.

This has been changed, so that we now use the ~/doltgres/databases folder by default. This means that it is now irrelevant where you run doltgres from, as it will always access that folder. If you want to use a different folder then you can use the --data-dir argument. If a relative path is given, then that is relative to the invocation directory. If an absolute path is given, then that path is used. In addition, there's now a DOLTGRES_DATA_DIR environment variable, which accomplishes the same thing as the --data-dir argument, except that you don't have to include the argument every time you run the binary. To mimic the previous behavior, you can set the argument or environment variable to ., which will use the invocation directory.

Merged PRs

doltgresql

• 79: Added static analyzer & linter
  This adds a static analyzer and linter. This is just to help enforce a bit more code quality.
• 78: Changed default database creation behavior
  Previously, when running doltgres, it would look at the current directory to determine if it was a valid DoltgreSQL directory. If it wasn't, then it would attempt to create a doltgres database within the directory. This behavior was chosen since "it just works", which is a selling point of the product. This was causing issues though, as users would run the tool from within the same directory that they downloaded it in. This caused an error message to appear stating that the file was conflicting with the attempt to create the database, however users were still confused by the behavior even with the error message.
  This default behavior has been changed. We now use the ~/doltgres/databases directory as the default directory. It no longer matters where you run doltgres from, it will always point to that directory. This directory can be changed by changing the environment variable DOLTGRES_DATA_DIR to a different directory.
  In addition, there's another environment variable named DOLTGRES_DATA_DIR_CWD. When this is set to true, then it causes DoltgreSQL to operate with the previous behavior, in that it will use the current directory rather than the global data directory.
• 77: End to end tests of all postgres types (many skipped)
  Behavior and syntax verified against postgres, but many of them may require custom types instead of strings when implemented.
• 74: Test generation framework additions
  I ran into too many issues while trying to generate a set of SELECT tests to add to sqllogictests, but I think this code here could still be useful in the future. The SELECT statements were too complex for random generation to happen upon a valid combination of queries, aliases, values, etc., but this could still have use for simpler statements. Since our synopses are written in a small DSL, you could technically generate anything as long as random generation is viable. It's basically what I've done for a lot of the generated tests throughout GMS and Dolt, but more formalized here.
• 73: Correct issue test
  #25 was incorrect in its assumptions, but still proved valuable for learning. As a result, I've modified the skipped test so that we're now checking the same relative thing.
• 72: Fix release notes generator
• 71: Release v0.2.0
  Created by the Release workflow to update DoltgreSQL's version
• 66: Contribution Guide
  Contribution guide. Primarily intended for Dolt devs transitioning to DoltgreSQL, but also written for anyone who wants to work on the repository. Now I can link to the document for some feedback, rather than leaving a paragraph on why it's important to change something lol.
• 65: Add usage metrics to doltgres
  Usage metrics are now reported to the dolthub metrics servers for the sql-server command, tagged with the doltgres application ID.
  Also refactors application and server start to put top-level concerns in the main method.

Closed Issues

• 43: No databases on macOS arm64?
• 44: Document backup and replication needs/compability
• 25: call dolt_branch("br1") errors