Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, david(at)fetter(dot)org, Oliver Ford <ojford(at)gmail(dot)com>, Krasiyan Andreev <krasiyan(at)gmail(dot)com>
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Date: 2018-09-25 04:16:27
Message-ID: 8736tygr5e.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So I've tried to rough out a decision tree for the various options on
how this might be implemented (discarding the "use precedence hacks"
option). Opinions? Additions?

(formatted for emacs outline-mode)

* 1. use lexical lookahead

+: relatively straightforward parser changes
+: no new reserved words
+: has the option of working extensibly with all functions

-: base_yylex needs extending to 3 lookahead tokens

** 1.1. Allow from/ignore clause on all (or all non-agg) window function calls

If the clauses are legal on all window functions, what to do about existing
window functions for which the clauses do not make sense?

*** 1.1.1. Ignore the clause when the function isn't aware of it

+: simple
-: somewhat surprising for users perhaps?

*** 1.1.2. Change the behavior of the windowapi in some consistent way

Not sure if this can work.
+: fairly simple(maybe?) and predictable
-: changes the behavior of existing window functions

** 1.2. Allow from/ignore clause on only certain functions

+: avoids any unexpected behavior
-: needs some way to control what functions allow it

*** 1.2.1. Check the function name in parse analysis against a fixed list.

+: simple
-: not extensible

*** 1.2.2. Provide some option in CREATE FUNCTION

+: extensible
-: fairly intrusive, adding stuff to create function and pg_proc

*** 1.2.3. Do something magical with function argument types

+: doesn't need changes in create function / pg_proc
-: it's an ugly hack

* 2. reserve nth_value etc. as functions

+: follows the spec reasonably well
+: less of a hack than extending base_yylex

-: new reserved words
-: more parser rules
-: not extensible

(now goto 1.2.1)

* 3. "just say no" to the spec

e.g. add new functions like lead_ignore_nulls(), or add extra boolean
args to lead() etc. telling them to skip nulls

+: simple
-: doesn't conform to spec
-: using extra args isn't quite the right semantics

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-09-25 04:27:35 Re: Proposal for Signal Detection Refactoring
Previous Message Haribabu Kommi 2018-09-25 03:49:09 Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query