Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g4o00-0002b1-QD for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Sep 2018 14:07:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g4nzx-0008KL-Lb for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Sep 2018 14:07:33 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g4nzx-0008K6-1l for pgsql-hackers@lists.postgresql.org; Tue, 25 Sep 2018 14:07:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g4nzq-0003IH-HO for pgsql-hackers@postgresql.org; Tue, 25 Sep 2018 14:07:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w8PE7JKH005568; Tue, 25 Sep 2018 10:07:19 -0400 From: Tom Lane To: Andrew Gierth cc: pgsql-hackers@postgresql.org, david@fetter.org, Oliver Ford , Krasiyan Andreev Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options In-reply-to: <8736tygr5e.fsf@news-spur.riddles.org.uk> References: <20180728185958.GP17411@fetter.org> <878t3vj279.fsf@news-spur.riddles.org.uk> <2897.1537737232@sss.pgh.pa.us> <87va6vhoey.fsf@news-spur.riddles.org.uk> <9361.1537744225@sss.pgh.pa.us> <8736tygr5e.fsf@news-spur.riddles.org.uk> Comments: In-reply-to Andrew Gierth message dated "Tue, 25 Sep 2018 05:16:27 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5566.1537884439.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Sep 2018 10:07:19 -0400 Message-ID: <5567.1537884439@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andrew Gierth writes: > 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? I think it'd be worth at least drafting an implementation for the lexical-lookahead fix. I think it's likely that we'll need to extend base_yylex to do more lookahead in the future even if we don't do it for this, given the SQL committee's evident love for COBOL-ish syntax and lack of regard for what you can do in LALR(1). The questions of how we interface to the individual window functions are really independent of how we handle the parsing problem. My first inclination is to just pass the flags down to the window functions (store them in WindowObject and provide some additional inquiry functions in windowapi.h) and let them deal with it. > If the clauses are legal on all window functions, what to do about exi= sting > window functions for which the clauses do not make sense? Option 1: do nothing, document that nothing happens if w.f. doesn't implement it. Option 2: record whether the inquiry functions got called. At end of query, error out if they weren't and the options were used. It's also worth wondering if we couldn't just implement the flags in some generic fashion and not need to involve the window functions at all. FROM LAST, for example, could and perhaps should be implemented by inverting the sort order. Possibly IGNORE NULLS could be implemented inside the WinGetFuncArgXXX functions? These behaviors might or might not make much sense with other window functions, but that doesn't seem like it's our problem. regards, tom lane