-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql/parser: comment out/disable unsupported portions of SQL grammar #1949
Comments
Yeah, there isn't another issue for this. There are still swaths of the grammar for which there are no semantic actions. We need to either comment these out or remove them when there is no desire to implement them (e.g. the recently removed postgres extension for generic literal syntax). |
@petermattis should this be closed now that #2060 is in? |
Not yet. There are still portions of the grammar which do not have supporting semantic actions. For example, |
Removed support for typed tables (CREATE TABLE ... OF <type>) which take their structure from a composite type. We've already removed support for custom types, so this was just detritus. Removed support for the INHERITS, WITH and ON COMMIT clauses to CREATE TABLE. It is possible these will be reconstituted at some point, but their implementation is not in any near term roadmap. Removed support for the generalized forms of "ALTER TABLE COLUMN x {SET,RESET}". Leave support for SET NULL and SET NOT NULL. Removed support for a few other "ALTER TABLE" commands that we're unlikely to support ("SET {LOGGED,UNLOGGED}", etc). Removed support for "CREATE TABLE ... AS <query>". This can be accomplished by creating the table and populating it with "INSERT INTO <table> <query>". Removed support for the RETURNING clause (a postgres extension) for delete, insert and update statements. Removes support for "ALTER DATABASE name" (which seemed to be useless) and "ALTER DATABASE name SET var = value". We don't have any use for the latter syntax at this point and can reconstitute in the future if needed. See #1949.
The "func" table stuff is nowhere on the current roadmap. See postgres functions like normal_rand(). LATERAL joins are a relatively recent addition to postgres that we're unlikely to support any time soon, if ever. See #1949.
Added an unimplemented() function that is called from any semantic action that is unimplemented() and that is not intentionally blank. Fixes #1949.
(thought we had an issue for this already, but could not find it).
The text was updated successfully, but these errors were encountered: