Add PostgreSQL CREATE/ALTER TEXT SEARCH DDL Parsing#2250
Add PostgreSQL CREATE/ALTER TEXT SEARCH DDL Parsing#2250LucaCappelletti94 wants to merge 3 commits intoapache:mainfrom
CREATE/ALTER TEXT SEARCH DDL Parsing#2250Conversation
Introduce AST structures for CREATE/ALTER TEXT SEARCH object types\n(dictionary, configuration, template, parser), including display\nimplementations, statement variants, From conversions, and span wiring.
Add parser support for CREATE/ALTER TEXT SEARCH DICTIONARY,\nCONFIGURATION, TEMPLATE, and PARSER forms, including operation-specific\nALTER clauses and strict CREATE option parsing.\n\nRegister text-search object names as parser keywords and reject unsupported\nCREATE modifiers for text-search objects.
Add regression coverage for the provided CREATE/ALTER TEXT SEARCH\nstatements and guardrails for rejected forms (quoted object type,\nmissing key/value option syntax, and unsupported CREATE modifiers).
| if or_replace || or_alter || temporary || global.is_some() || transient || persistent { | ||
| return Err(ParserError::ParserError( | ||
| "CREATE TEXT SEARCH does not support CREATE modifiers".to_string(), | ||
| )); | ||
| } |
There was a problem hiding this comment.
| if or_replace || or_alter || temporary || global.is_some() || transient || persistent { | |
| return Err(ParserError::ParserError( | |
| "CREATE TEXT SEARCH does not support CREATE modifiers".to_string(), | |
| )); | |
| } |
I think we can skip this validation and leave up to downstream crates if desired
There was a problem hiding this comment.
Well this is not semantics, it would be constructing a syntax tree that is not currently valid syntax in any of the supported dialects. I have already encountered this genre of issue a few times and I am a bit confused as to which direction should be preferable.
You would prefer going for the permissive route?
| && self.parse_one_of_keywords(&[Keyword::PERSISTENT]).is_some(); | ||
| let create_view_params = self.parse_create_view_params()?; | ||
| if self.parse_keyword(Keyword::TABLE) { | ||
| if self.parse_keywords(&[Keyword::TEXT, Keyword::SEARCH]) { |
There was a problem hiding this comment.
instead of parse, can we 'peek' TEXT, SEARCH? so that parse_create_text_search() can be somewhat standalone
| let object_type = self.parse_text_search_object_type()?; | ||
| let name = self.parse_object_name(false)?; | ||
| self.expect_token(&Token::LParen)?; | ||
| let options = self.parse_comma_separated(Parser::parse_text_search_option)?; |
There was a problem hiding this comment.
| let options = self.parse_comma_separated(Parser::parse_text_search_option)?; | |
| let options = self.parse_comma_separated(Parser::parse_sql_option)?; |
I think we can reuse this parser given it matches the representation
| ]; | ||
|
|
||
| for sql in sql_cases { | ||
| if let Err(err) = pg().parse_sql_statements(sql) { |
There was a problem hiding this comment.
can the tests use verified_statement, also pg_and_generic() where possible?
| "CREATE TEXT SEARCH DICTIONARY alt_ts_dict1 (template=simple)", | ||
| "CREATE TEXT SEARCH DICTIONARY alt_ts_dict2 (template=simple)", |
There was a problem hiding this comment.
could we do a pass through the test cases to remove duplicate/superfluous cases? (for example the first two highlighted here seem identical and expected to cover the same codepaths)
There was a problem hiding this comment.
These are all distinct tests cases from the postgres regression corpus, I just included all of the associated ones. That being said, some really seem identical to each other. I will trim them down.
2 participants
Adds parser and AST support for PostgreSQL text search DDL statements:
CREATE TEXT SEARCH DICTIONARY ...CREATE TEXT SEARCH CONFIGURATION ...CREATE TEXT SEARCH TEMPLATE ...CREATE TEXT SEARCH PARSER ...ALTER TEXT SEARCH DICTIONARY ...ALTER TEXT SEARCH CONFIGURATION ...ALTER TEXT SEARCH TEMPLATE ...ALTER TEXT SEARCH PARSER ...The work also adds focused regression coverage for previously failing cases.