Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgres-lambda-diff

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Andrew Gierth authored
    Previously, parseCheckAggregates was run before
    assign_query_collations, but this causes problems if any expression
    has already had a collation assigned by some transform function (e.g.
    transformCaseExpr) before parseCheckAggregates runs. The differing
    collations would cause expressions not to be recognized as equal to
    the ones in the GROUP BY clause, leading to spurious errors about
    unaggregated column references.
    
    The result was that CASE expr WHEN val ... would fail when "expr"
    contained a GROUPING() expression or matched one of the group by
    expressions, and where collatable types were involved; whereas the
    supposedly identical CASE WHEN expr = val ... would succeed.
    
    Backpatch all the way; this appears to have been wrong ever since
    collations were introduced.
    
    Per report from Guillaume Lelarge, analysis and patch by me.
    
    Discussion: https://postgr.es/m/CAECtzeVSO_US8C2Khgfv54ZMUOBR4sWq+6_bLrETnWExHT=rFg@mail.gmail.com
    Discussion: https://postgr.es/m/87muo0k0c7.fsf@news-spur.riddles.org.uk
    174fab99
    History
    Name Last commit Last update