-
Notifications
You must be signed in to change notification settings - Fork 39
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
Postgres DEFAULT statement with "at time zone" causes entire CREATE statement to be omitted from results #112
Comments
@James-Matthew-Watson , hi! Thanks for explicit description & ddl samples. I will add support for statements with ‘at time zone’. About the exception there is a another issue for that. Problem that there is no way really to identify issue why it is not parsed. So it will be error raise, but with common error like “Hey, looks like empty output in parser, possibly some statements unsupported”. Maybe without “Hey”))) |
@James-Matthew-Watson fix was added at version 0.25.0 https://github.com/xnuinside/simple-ddl-parser/blob/main/tests/test_simple_ddl_parser.py#L2507 sorry for the delay - was on exam session & became sick(. If you will have any other issues - feel free to open the ticket. Also, in version 0.25.0 was added flag 'silent'. You can pass to parser 'silent=False' and it will raise the errors |
Description
When trying out simple-ddl-parser on some existing DDL, I attempted to parse 4 CREATE statements but I would only get 3 results. No exception was produced. By process of elimination, I found that this line was the source of the issue:
created_timestamp TIMESTAMPTZ NOT NULL DEFAULT (now() at time zone 'utc'),
However. with the following, the CREATE statement is parsed as expected:
created_timestamp TIMESTAMPTZ NOT NULL DEFAULT (now()),
Which suggests that the issue is around the "at time zone 'utc'" portion of the DFEAULT clause.
To Reproduce
Parse a CREATE statement including a TIMESTAMPTZ column with a DEFAULT clause including
at time zone 'utc'
. NOTE: the specific time zone used does not appear to matter.Expected behavior
The CREATE statement should be parsed and included in parsing results. Although this statement is valid Postgres DDL, I would expect an exception when a statement is not parseable or at something other than just ignoring the CREATE statement. I did not see anything in the documentation about error handling, I apologize if I have overlooked that.
Example code
Expected output: 1 followed by the table name: 'example'
Actual output: 0
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: