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

shippable.c

Blame
    • Tom Lane's avatar
      d8949416
      Allow postgres_fdw to ship extension funcs/operators for remote execution. · d8949416
      Tom Lane authored
      The user can whitelist specified extension(s) in the foreign server's
      options, whereupon we will treat immutable functions and operators of those
      extensions as candidates to be sent for remote execution.
      
      Whitelisting an extension in this way basically promises that the extension
      exists on the remote server and behaves compatibly with the local instance.
      We have no way to prove that formally, so we have to rely on the user to
      get it right.  But this seems like something that people can usually get
      right in practice.
      
      We might in future allow functions and operators to be whitelisted
      individually, but extension granularity is a very convenient special case,
      so it got done first.
      
      The patch as-committed lacks any regression tests, which is unfortunate,
      but introducing dependencies on other extensions for testing purposes
      would break "make installcheck" scenarios, which is worse.  I have some
      ideas about klugy ways around that, but it seems like material for a
      separate patch.  For the moment, leave the problem open.
      
      Paul Ramsey, hacked up a bit more by me
      d8949416
      History
      Allow postgres_fdw to ship extension funcs/operators for remote execution.
      Tom Lane authored
      The user can whitelist specified extension(s) in the foreign server's
      options, whereupon we will treat immutable functions and operators of those
      extensions as candidates to be sent for remote execution.
      
      Whitelisting an extension in this way basically promises that the extension
      exists on the remote server and behaves compatibly with the local instance.
      We have no way to prove that formally, so we have to rely on the user to
      get it right.  But this seems like something that people can usually get
      right in practice.
      
      We might in future allow functions and operators to be whitelisted
      individually, but extension granularity is a very convenient special case,
      so it got done first.
      
      The patch as-committed lacks any regression tests, which is unfortunate,
      but introducing dependencies on other extensions for testing purposes
      would break "make installcheck" scenarios, which is worse.  I have some
      ideas about klugy ways around that, but it seems like material for a
      separate patch.  For the moment, leave the problem open.
      
      Paul Ramsey, hacked up a bit more by me