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
    Previously, text between backquotes in a psql metacommand's arguments
    was always passed to the shell literally.  That considerably hobbles
    the usefulness of the feature for scripting, so we'd foreseen for a long
    time that we'd someday want to allow substitution of psql variables into
    the shell command.  IMO the addition of \if metacommands has brought us to
    that point, since \if can greatly benefit from some sort of client-side
    expression evaluation capability, and psql itself is not going to grow any
    such thing in time for v10.  Hence, this patch.  It allows :VARIABLE to be
    replaced by the exact contents of the named variable, while :'VARIABLE'
    is replaced by the variable's contents suitably quoted to become a single
    shell-command argument.  (The quoting rules for that are different from
    those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
    notation, but I doubt anyone will be confused.)
    
    As with other situations in psql, no substitution occurs if the word
    following a colon is not a known variable name.  That limits the risk of
    compatibility problems for existing psql scripts; but the risk isn't zero,
    so this needs to be called out in the v10 release notes.
    
    Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
    f833c847
    History
    Name Last commit Last update