Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse Postgres's LOCK TABLE statement #1614

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

freshtonic
Copy link

See: https://www.postgresql.org/docs/current/sql-lock.html

PG's full syntax for this statement is supported:

LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ IN lockmode MODE ] [ NOWAIT ]

where lockmode is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE

It is implemented to not intefere with the roughly equivalent (but different) syntax in MySQL, by using a new Statement variant.

tobyhede and others added 3 commits December 20, 2024 12:15
See: https://www.postgresql.org/docs/current/sql-lock.html

PG's full syntax for this statement is supported:

```
LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ IN lockmode MODE ] [ NOWAIT ]

where lockmode is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
```

It is implemented to not intefere with the roughly equivalent (but
different) syntax in MySQL, by using a new Statement variant.
@freshtonic freshtonic force-pushed the james/cip-1063-add-lock-table-support-in-sqlparser branch from 7ce8f33 to 47a3e5e Compare December 20, 2024 05:38
Copy link
Contributor

@iffyio iffyio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @freshtonic!

Comment on lines +9607 to +9613
let projection = if dialect_of!(self is PostgreSqlDialect | GenericDialect)
&& self.peek_keyword(Keyword::FROM)
{
vec![]
} else {
self.parse_projection()?
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can probably skip these changes in this PR given it's now in #1613?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iffyio oh my bad - I should have branched from the apache main branch instead of our fork's main before pushing. I'll remedy this.

/// | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
///
/// Note: this is a Postgres-specific statement. See <https://www.postgresql.org/docs/current/sql-lock.html>
LockTablesPG {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we take a look at merging this into the existing Statement::LockTables variant? I think that would be the desirable path forward in order to avoid duplicating the statement type

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try doing that. FWIW the reason I didn't to begin with is that at it seemed like the MySQL version of the LOCK ... statement is quite different to PG's, but I didn't think too hard about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants