Thanks for the feedback. For the parsing changes, it seems I can either make RESPECT and IGNORE reserved keywords, or add a lookahead to construct synthetic RESPECT NULLS and IGNORE NULLS keywords. The grammar wouldn't compile if RESPECT and IGNORE were just normal unreserved keywords due to ambiguities after a function definition (e.g. select abs(1) respect; - which is currently a valid statement).
I've redone the leadlag function changes to use datumCopy as you suggested. However, I've had to remove the NOT_USED #ifdef around datumFree so I can use it to avoid building up large numbers of copies of Datums in the memory context while a query is executing. I've attached the revised patch... Thanks - Nick On 24 March 2013 03:43, Hitoshi Harada <umi.tan...@gmail.com> wrote: > > > On Sat, Mar 23, 2013 at 3:25 PM, Nicholas White <n.j.wh...@gmail.com>wrote: > >> Thanks - I've added it here: >> https://commitfest.postgresql.org/action/patch_view?id=1096 . >> >> I've also attached a revised version that makes IGNORE and RESPECT >> UNRESERVED keywords (following the pattern of NULLS_FIRST and NULLS_LAST). >> > > Hm, you made another lookahead in base_yylex to make them unreserved -- > looks ok, but not sure if there was no way to do it. > > You might want to try byref types such as text. It seems you need to copy > the datum to save the value in appropriate memory context. Also, try to > create a view on those expressions. I don't think it correctly preserves > it. > > Thanks, > -- > Hitoshi Harada
lead-lag-ignore-nulls.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
