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

parse_expr.c

Blame
    • Bruce Momjian's avatar
      cf374feb
      >Turning nextval and currval into keywords is not an acceptable way to · cf374feb
      Bruce Momjian authored
      >go about this.  That will risk breaking existing applications that use
      >those names as column names.
      >
      >It should actually almost work to write sq.nextval as things stand,
      >because Postgres has for a long time considered table.function and
      >function(table) to be interchangeable notations for certain kinds of
      >functions.  nextval doesn't seem to be one of that kind of function,
      >at the moment.  I'd suggest leaving the grammar as it was, and taking a
      >look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
      >it to accept the sequence functions in that style.
      
      OK, good point. I tried to implement it somewhere else and ended up
      extending transformAttr. Attached you'll find the patch.
      
      Jeroen van Vianen
      cf374feb
      History
      >Turning nextval and currval into keywords is not an acceptable way to
      Bruce Momjian authored
      >go about this.  That will risk breaking existing applications that use
      >those names as column names.
      >
      >It should actually almost work to write sq.nextval as things stand,
      >because Postgres has for a long time considered table.function and
      >function(table) to be interchangeable notations for certain kinds of
      >functions.  nextval doesn't seem to be one of that kind of function,
      >at the moment.  I'd suggest leaving the grammar as it was, and taking a
      >look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
      >it to accept the sequence functions in that style.
      
      OK, good point. I tried to implement it somewhere else and ended up
      extending transformAttr. Attached you'll find the patch.
      
      Jeroen van Vianen