V good first issues

This issue describes a bug where an UPDATE statement incorrectly rewrites a row even when a NULL column is explicitly set to NULL. This unnecessary write operation incurs performance costs and can lead to serialization failures in concurrent transactions. The proposed solution is to treat setting a NULL column to NULL as an unchanged state while still counting it in the UPDATE operation.

This issue requests the implementation of support for the `TABLE ...` statement, which is described as an alternative syntax for `SELECT * FROM ...`. This enhancement would expand the query language capabilities.

This issue reports a syntax error when using `FETCH NEXT` or `FETCH FIRST` clauses without explicitly specifying a row count. The SQL standard indicates that omitting the count should default to 1 row, but the current implementation is not supporting this behavior, leading to errors.

The SQL parser is not recognizing 'DEC' as a valid alias for the 'DECIMAL' data type, despite it being a standard and documented abbreviation. This issue requires an update to the parser's recognized type names to include 'DEC'.

This issue proposes an optimization to reduce overhead in a database system. By keeping the `.isolation` file open for the duration of a connection, similar to the `.session` file, it aims to eliminate repeated file open/close operations for each database-modifying statement. This change is expected to improve performance, particularly for bulk insert operations.

Transactions using `REPEATABLE READ` or `SERIALIZABLE` isolation levels can experience unfair waiting for an isolation lock, leading to timeouts and serialization failures. The current polling mechanism allows connections that just committed to immediately reacquire the lock, starving waiting transactions. The issue proposes implementing a fairer queuing mechanism, potentially using ticket numbers or blocking `flock()` calls, to ensure equitable access to the isolation lock.

This issue proposes implementing snapshot isolation for REPEATABLE READ transactions. This change aims to improve concurrency by preventing REPEATABLE READ transactions from blocking other writers, unlike the current implementation which behaves like SERIALIZABLE. The proposed solution involves taking a snapshot at the start of the transaction and using it for visibility checks, with mechanisms to handle write conflicts and version cleanup.

This issue proposes optimizing query performance by evaluating constant expressions once during query planning instead of repeatedly for each row. This would significantly improve efficiency for operations like primary key lookups, which are currently bypassed when the comparison value is a constant expression rather than a literal. The implementation needs to carefully handle data types, potential errors, and the distinction between constant and non-constant expressions.

This issue proposes an optimization for SQL queries where uncorrelated subqueries are repeatedly executed for each row of the outer query. The goal is to evaluate such subqueries only once per statement and cache their results, significantly improving performance for queries with independent subqueries.

This issue describes a performance regression where using a correlation name (alias) for a table with an integer primary key prevents the database from using the primary key for efficient lookups. Instead, it performs a full table scan. The problem stems from the planner's text-based matching for primary key lookups, which fails when correlation names or qualified column names are involved.

This issue proposes optimizing the `IN` predicate by short-circuiting the evaluation once a match is found. Currently, it iterates through the entire list for every row, even if an earlier element matches. The suggested solution involves checking type comparability during compilation to enable early termination and prevent order-dependent errors, with a further enhancement to use hash sets for literal lists.

The `distinct_values` function for set operations like `COUNT(DISTINCT x)` currently has an O(n²) time complexity due to its duplicate removal method. This leads to performance degradation on large datasets. The issue proposes an O(n) solution by leveraging the PRIMARY KEY encoding, which groups equal values together, allowing for efficient deduplication using a map.

This issue proposes adding support for CASCADE and RESTRICT clauses to the `DROP TABLE` and `DROP SEQUENCE` SQL commands. Currently, these commands only support dropping objects without specifying a behavior, which deviates from the SQL standard. Implementing this would align the database with standard syntax and improve its flexibility.

This issue reports that the `POSITION` function in SQL returns 0 when searching for an empty string, even though the general rule states it should return 1 if the character length of the first argument is 0. This behavior is observed in both cases where the string being searched is non-empty and empty.

This issue describes a bug where creating a sequence with a name that already exists does not raise an error as expected. Instead, it succeeds without reporting a duplicate object error, which violates the expected syntax rules for sequence creation.

This issue reports a bug where the row count reported by an UPDATE statement is incorrect. It should count all rows that match the WHERE clause, even if their values don't actually change. The provided SQL example demonstrates this discrepancy, and affected tests are also identified.

This issue requests the addition of a `docker-compose.yml` file to the project. The goal is to simplify deployment by allowing users to start the application with a single `docker-compose up -d` command.

The issue describes a syntax error where the approximate numeric literal '5.e1' is not accepted by the SQL parser. The user believes this should be valid based on the defined grammar, suggesting a potential bug in how approximate numeric literals with a trailing decimal point are handled.

A bug exists where the table name displayed in a 23505 unique constraint violation error differs based on how the table was created (directly vs. loaded from a file). This inconsistency stems from how the table name is stored and resolved in different code paths, leading to unexpected error messages.

The issue describes a syntax error in SQL when trying to create a table with a delimited identifier containing a double quote. The current implementation incorrectly interprets `""` within an identifier as an escape sequence, rather than a literal double quote, leading to a syntax error. The fix involves correctly handling escaped double quotes within delimited identifiers.

The issue describes a bug where a SQL `VALUES` clause allows rows with differing numbers of columns, which violates the SQL standard. This should be a syntax error, but instead, it leads to a runtime error during CLI execution.

This issue reports that several numeric functions in the SQL implementation are returning NaN or infinity instead of raising the expected SQLSTATE errors for invalid arguments. Examples include SQRT(-1), LN(0), LOG10(-5), POWER(0, -1), ASIN(2), and ACOS(-2). The formatting of the `-+infe0` output is also noted as unusual.

This issue describes a bug where invalid regular expressions used with the SIMILAR TO operator in SQL result in internal regexp errors instead of the expected SQLSTATE 2201B for invalid regular expressions. The report also points out an inconsistency in how quantifiers like '{,2}' are handled, suggesting they should adhere to stricter syntax rules.

This issue proposes adding support for SQL comments, specifically single-line comments starting with '--' and multi-line comments enclosed in '/* ... */'. The provided grammar defines the structure of these comment types.

The user is reporting that the SQL syntax 'FETCH FIRST ROW ONLY' is not working as expected, despite being valid SQL. This suggests a potential bug in how the database system is interpreting or executing this specific clause.

This issue highlights that the precision specifier 'n' in the `FLOAT(n)` data type is currently ignored by the system. The standard's ambiguity regarding the expected behavior of this specifier makes it challenging to implement correctly.

The user is encountering an error when trying to insert data into a table, specifically "cannot create lock file sample2.vsql.lock". This suggests a problem with file system permissions or the database's ability to acquire a lock on the specified file, preventing the operation from completing.

This issue highlights that the LIKE and SIMILAR TO operators in the database system do not currently support the ESCAPE clause, which is intended to allow for specifying a character to escape wildcard characters in patterns. The user has provided the relevant grammar snippets showing where the ESCAPE clause should be supported, indicating a need for an enhancement to add this functionality.

This enhancement request aims to allow PRIMARY KEY constraints to be defined with multiple columns in the SQL dialect. Currently, the system only supports single-column primary keys, limiting database schema design flexibility.

The help output for the `shuf` command in V Coreutils differs from the GNU version, specifically in the formatting and descriptions of options. This discrepancy could lead to user confusion when trying to understand or use the command.