{"push_id":2312091856,"size":2,"distinct_size":1,"ref":"refs/heads/commitfest/16/1250","head":"86f9857422b7f4914930c6413dc5c7c0f88c8919","before":"9162f43cf628dd7ff9d1c00f024481b0aaf47f88","commits":[{"sha":"0a459cec96d3856f476c2db298c6b52f592894e8","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Support all SQL:2011 options for window frame clauses.\n\nThis patch adds the ability to use \"RANGE offset PRECEDING/FOLLOWING\"\nframe boundaries in window functions.  We'd punted on that back in the\noriginal patch to add window functions, because it was not clear how to\ndo it in a reasonably data-type-extensible fashion.  That problem is\nresolved here by adding the ability for btree operator classes to provide\nan \"in_range\" support function that defines how to add or subtract the\nRANGE offset value.  Factoring it this way also allows the operator class\nto avoid overflow problems near the ends of the datatype's range, if it\nwishes to expend effort on that.  (In the committed patch, the integer\nopclasses handle that issue, but it did not seem worth the trouble to\navoid overflow failures for datetime types.)\n\nThe patch includes in_range support for the integer_ops opfamily\n(int2/int4/int8) as well as the standard datetime types.  Support for\nother numeric types has been requested, but that seems like suitable\nmaterial for a follow-on patch.\n\nIn addition, the patch adds GROUPS mode which counts the offset in\nORDER-BY peer groups rather than rows, and it adds the frame_exclusion\noptions specified by SQL:2011.  As far as I can see, we are now fully\nup to spec on window framing options.\n\nExisting behaviors remain unchanged, except that I changed the errcode\nfor a couple of existing error reports to meet the SQL spec's expectation\nthat negative \"offset\" values should be reported as SQLSTATE 22013.\n\nInternally and in relevant parts of the documentation, we now consistently\nuse the terminology \"offset PRECEDING/FOLLOWING\" rather than \"value\nPRECEDING/FOLLOWING\", since the term \"value\" is confusingly vague.\n\nOliver Ford, reviewed and whacked around some by me\n\nDiscussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/0a459cec96d3856f476c2db298c6b52f592894e8"},{"sha":"86f9857422b7f4914930c6413dc5c7c0f88c8919","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 16/1250] Partition-wise aggregation/grouping\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread or the master branch changes.\n\nCommitfest entry: https://commitfest.postgresql.org/16/1250\nPatch(es): https://www.postgresql.org/message-id/CAM2%2B6%3DUpcC0cmmQhKrZaP7d%2BskRg21z706epMWJbcER_NvLK4g%40mail.gmail.com\nAuthor(s): Jeevan Chalke","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/86f9857422b7f4914930c6413dc5c7c0f88c8919"}]}
{"actor":{"display_login":"postgresql-cfbot"}}