Re: Row pattern recognition - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Row pattern recognition
Date
Msg-id 20251119.161903.739789959387305008.ishii@postgresql.org
Whole thread Raw
In response to Re: Row pattern recognition  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
> 2 - 0001 - gram.y
> ```
> opt_row_pattern_initial_or_seek:
>             INITIAL        { $$ = true; }
>             | SEEK
>                 {
>                     ereport(ERROR,
>                             (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>                              errmsg("SEEK is not supported"),
>                              errhint("Use INITIAL instead."),
>                              parser_errposition(@1)));
>                 }
>             | /*EMPTY*/        { $$ = true; }
>         ;
> ```
> 
> As SEEK is specially listed here, I guess it might be supported in future. If that is true, would it be better to
deferthe semantic check to later parse phase, which would future work easier.
 

From a comment in gram.y:

/*
 * If we see PARTITION, RANGE, ROWS, GROUPS, AFTER, INITIAL, SEEK or PATTERN_P
 * as the first token after the '(' of a window_specification, we want the
 * assumption to be that there is no existing_window_name; but those keywords
 * are unreserved and so could be ColIds.  We fix this by making them have the

For this purpose, we want INITIAL and SEEK to be unreserved keywords.

> 3 - 0001 - parsenodes.h
> ```
> +/*
> + * RowPatternCommonSyntax - raw representation of row pattern common syntax
> + *
> + */
> +typedef struct RPCommonSyntax
> +{
> +    NodeTag        type;
> +    RPSkipTo    rpSkipTo;        /* Row Pattern AFTER MATCH SKIP type */
> +    bool        initial;        /* true if <row pattern initial or seek> is
> +                                 * initial */
> +    List       *rpPatterns;        /* PATTERN variables (list of A_Expr) */
> +    List       *rpDefs;            /* row pattern definitions clause (list of
> +                                 * ResTarget) */
> +} RPCommonSyntax;
> +
>  /*
>   * WindowDef - raw representation of WINDOW and OVER clauses
>   *
> @@ -593,6 +618,7 @@ typedef struct WindowDef
>      char       *refname;        /* referenced window name, if any */
>      List       *partitionClause;    /* PARTITION BY expression list */
>      List       *orderClause;    /* ORDER BY (list of SortBy) */
> +    RPCommonSyntax *rpCommonSyntax; /* row pattern common syntax */
> ```
> 
> RP fields are directly defined in WindowClause, then why do we need a wrapper of RPCommonSyntax? Can we directly
defineRP fields in WindowRef as well?
 

The row pattern common syntax defined in the standard is not only used
in the WINDOW clause, but in the FROM clause. If we would support RPR
in FROM clause in the future, it would be better to use the same code
of row pattern common syntax in WINDOW clause as much as
possible. That's the reason I created RPCommonSyntax. In the
parse/analysis phase, I am not sure how the parse/analysis code would
be in FROM clause at this point. So I did not define yet another
struct for it.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: David Geier
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?