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

plpython_record.out

Blame
    • Peter Eisentraut's avatar
      ba3e4157
      PL/Python: Accept strings in functions returning composite types · ba3e4157
      Peter Eisentraut authored
      Before 9.1, PL/Python functions returning composite types could return
      a string and it would be parsed using record_in.  The 9.1 changes made
      PL/Python only expect dictionaries, tuples, or objects supporting
      getattr as output of composite functions, resulting in a regression
      and a confusing error message, as the strings were interpreted as
      sequences and the code for transforming lists to database tuples was
      used.  Fix this by treating strings separately as before, before
      checking for the other types.
      
      The reason why it's important to support string to database tuple
      conversion is that trigger functions on tables with composite columns
      get the composite row passed in as a string (from record_out).
      Without supporting converting this back using record_in, this makes it
      impossible to implement pass-through behavior for these columns, as
      PL/Python no longer accepts strings for composite values.
      
      A better solution would be to fix the code that transforms composite
      inputs into Python objects to produce dictionaries that would then be
      correctly interpreted by the Python->PostgreSQL counterpart code.  But
      that would be too invasive to backpatch to 9.1, and it is too late in
      the 9.2 cycle to attempt it.  It should be revisited in the future,
      though.
      
      Reported as bug #6559 by Kirill Simonov.
      
      Jan Urbański
      ba3e4157
      History
      PL/Python: Accept strings in functions returning composite types
      Peter Eisentraut authored
      Before 9.1, PL/Python functions returning composite types could return
      a string and it would be parsed using record_in.  The 9.1 changes made
      PL/Python only expect dictionaries, tuples, or objects supporting
      getattr as output of composite functions, resulting in a regression
      and a confusing error message, as the strings were interpreted as
      sequences and the code for transforming lists to database tuples was
      used.  Fix this by treating strings separately as before, before
      checking for the other types.
      
      The reason why it's important to support string to database tuple
      conversion is that trigger functions on tables with composite columns
      get the composite row passed in as a string (from record_out).
      Without supporting converting this back using record_in, this makes it
      impossible to implement pass-through behavior for these columns, as
      PL/Python no longer accepts strings for composite values.
      
      A better solution would be to fix the code that transforms composite
      inputs into Python objects to produce dictionaries that would then be
      correctly interpreted by the Python->PostgreSQL counterpart code.  But
      that would be too invasive to backpatch to 9.1, and it is too late in
      the 9.2 cycle to attempt it.  It should be revisited in the future,
      though.
      
      Reported as bug #6559 by Kirill Simonov.
      
      Jan Urbański