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

connection.c

Blame
    • Tom Lane's avatar
      cc3f281f
      Fix postgres_fdw's issues with inconsistent interpretation of data values. · cc3f281f
      Tom Lane authored
      For datatypes whose output formatting depends on one or more GUC settings,
      we have to worry about whether the other server will interpret the value
      the same way it was meant.  pg_dump has been aware of this hazard for a
      long time, but postgres_fdw needs to deal with it too.  To fix data
      retrieval from the remote server, set the necessary remote GUC settings at
      connection startup.  (We were already assuming that settings made then
      would persist throughout the remote session.)  To fix data transmission to
      the remote server, temporarily force the relevant GUCs to the right values
      when we're about to convert any data values to text for transmission.
      
      This is all pretty grotty, and not very cheap either.  It's tempting to
      think of defining one uber-GUC that would override any settings that might
      render printed data values unportable.  But of course, older remote servers
      wouldn't know any such thing and would still need this logic.
      
      While at it, revert commit f7951eef, since
      this provides a real fix.  (The timestamptz given in the error message
      returned from the "remote" server will now reliably be shown in UTC.)
      cc3f281f
      History
      Fix postgres_fdw's issues with inconsistent interpretation of data values.
      Tom Lane authored
      For datatypes whose output formatting depends on one or more GUC settings,
      we have to worry about whether the other server will interpret the value
      the same way it was meant.  pg_dump has been aware of this hazard for a
      long time, but postgres_fdw needs to deal with it too.  To fix data
      retrieval from the remote server, set the necessary remote GUC settings at
      connection startup.  (We were already assuming that settings made then
      would persist throughout the remote session.)  To fix data transmission to
      the remote server, temporarily force the relevant GUCs to the right values
      when we're about to convert any data values to text for transmission.
      
      This is all pretty grotty, and not very cheap either.  It's tempting to
      think of defining one uber-GUC that would override any settings that might
      render printed data values unportable.  But of course, older remote servers
      wouldn't know any such thing and would still need this logic.
      
      While at it, revert commit f7951eef, since
      this provides a real fix.  (The timestamptz given in the error message
      returned from the "remote" server will now reliably be shown in UTC.)