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
    Tom Lane authored
    The callers of UtilityContainsQuery want it to return a non-utility Query
    if it returns anything at all.  However, since we made CREATE TABLE
    AS/SELECT INTO into a utility command instead of a variant of SELECT,
    a command like "EXPLAIN SELECT INTO" results in two nested utility
    statements.  So what we need UtilityContainsQuery to do is drill down
    to the bottom non-utility Query.
    
    I had thought of this possibility in setrefs.c, and fixed it there by
    looping around the UtilityContainsQuery call; but overlooked that the call
    sites in plancache.c have a similar issue.  In those cases it's
    notationally inconvenient to provide an external loop, so let's redefine
    UtilityContainsQuery as recursing down to a non-utility Query instead.
    
    Noted by Rushabh Lathia.  This is a somewhat cleaned-up version of his
    proposed patch.
    bde689f8
    History
    Name Last commit Last update