Re: Possible bug: SQL function parameter in window frame definition - Mailing list pgsql-general

From Andrew Gierth
Subject Re: Possible bug: SQL function parameter in window frame definition
Date
Msg-id 87a7ammkaj.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Possible bug: SQL function parameter in window frame definition  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible bug: SQL function parameter in window frame definition
List pgsql-general
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >> Here is a draft patch along those lines; the intent of this one is
 >> that no existing walker or mutator should need to change (the change
 >> to the dependency code is basically cosmetic I believe, just avoids
 >> walking some things twice).

 Tom> Hmm.  I think this is a reasonable direction to go in, but
 Tom> what about groupingSets and rowMarks?

groupingSets ultimately contains nothing but numbers which are
meaningless without reference to the matching groupClause list. So
anything that cares about those is really going to have to process them
in its Query case in the walker function in order to get at both
clauses.

Similarly, rowMarks contains indexes into the rangetable (and no
recursive substructure at all), so it's likewise better processed at the
Query level.

 Tom> Also, in HEAD I'd be inclined to add assertions about utilityStmt
 Tom> being NULL.

Yup.

-- 
Andrew (irc:RhodiumToad)



pgsql-general by date:

Previous
From: Ben Chobot
Date:
Subject: Re: Redis 16 times faster than Postgres?
Next
From: Gerrit Fouche
Date:
Subject: pg_upgrade (Checking for reg* data types)