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

Custom type handling #186

Merged
merged 3 commits into from
Jul 29, 2023
Merged

Custom type handling #186

merged 3 commits into from
Jul 29, 2023

Conversation

matthias-Q
Copy link
Collaborator

This PR adds handling of custom types in Postgres:

  • create type
    • enum
    • range
    • object types
  • drop type
  • alter type
    • rename, rename attributes
    • drop, add, alter attributes
    • ownership & schema
  • create table with a column as a custom type
  • select from a table with a custom attribute (dot notation)

Remarks:
We have many statement with a set ( KEY = VALUE) section. The keys are often specific, but as of now we allow everything. They could be technically treated as keywords, but we have to add a lot of different variants. Or we keep it as it is and the parser will be more permissive.
(I think I asked this question before, but I don't remember the outcome of the discussion...)

References:
https://www.postgresql.org/docs/current/sql-createtype.html
https://www.postgresql.org/docs/current/sql-altertype.html
https://www.postgresql.org/docs/current/sql-droptype.html

Closes #184

@matthias-Q matthias-Q requested review from dmfay and DerekStride July 29, 2023 10:41
Copy link
Collaborator

@dmfay dmfay left a comment

Choose a reason for hiding this comment

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

We have many statement with a set ( KEY = VALUE) section. The keys are often specific, but as of now we allow everything. They could be technically treated as keywords, but we have to add a lot of different variants. Or we keep it as it is and the parser will be more permissive.
(I think I asked this question before, but I don't remember the outcome of the discussion...)

a lot of these get really dialect-specific so imo it's fine to be permissive with them

grammar.js Outdated Show resolved Hide resolved
grammar.js Outdated Show resolved Hide resolved
grammar.js Outdated Show resolved Hide resolved
test/corpus/custom_types.txt Outdated Show resolved Hide resolved
grammar.js Outdated Show resolved Hide resolved
test/corpus/custom_types.txt Outdated Show resolved Hide resolved
test/corpus/custom_types.txt Outdated Show resolved Hide resolved
test/corpus/custom_types.txt Outdated Show resolved Hide resolved
test/corpus/custom_types.txt Outdated Show resolved Hide resolved
grammar.js Outdated Show resolved Hide resolved
@matthias-Q
Copy link
Collaborator Author

I have change from identifier to literal for add/rename values of a custom type. It is now correct. However, it will also parse it as correct, when these fields are wrapped in double quotes. I think only single quotes will work. Maybe we should split the _literal_string in two hidden nodes so that we can used them separately.

Also, on my testing postgres instance this does not work:

ALTER TYPE color RENAME VALUE 'purple' TO 'mauve';

It is taken directly from the docs and it complaints about the keyword value. Am I missing something very obvious here?

@matthias-Q matthias-Q requested a review from dmfay July 29, 2023 16:37
@dmfay
Copy link
Collaborator

dmfay commented Jul 29, 2023

I have change from identifier to literal for add/rename values of a custom type. It is now correct. However, it will also parse it as correct, when these fields are wrapped in double quotes. I think only single quotes will work. Maybe we should split the _literal_string in two hidden nodes so that we can used them separately.

Also, on my testing postgres instance this does not work:

ALTER TYPE color RENAME VALUE 'purple' TO 'mauve';

It is taken directly from the docs and it complaints about the keyword value. Am I missing something very obvious here?

is the color type still an enum or did you recreate it as a composite while testing things?

[local] dian#dian= create type color as enum ('purple', 'red', 'yellow');
CREATE TYPE
Time: 14.847 ms
[local] dian#dian= alter type color rename value 'purple' to 'mauve';
ALTER TYPE
Time: 14.992 ms

re literal_string I think some dialects treat single/double quotes interchangeably but don't recall which offhand

@matthias-Q
Copy link
Collaborator Author

I just had a super old postgres version. I have updated to 15.3 and now it works.

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.

PG: Support creation and usage of custom types
2 participants