Re: postgresql FDW vs dblink for DDL - Mailing list pgsql-general

From Achilleas Mantzios
Subject Re: postgresql FDW vs dblink for DDL
Date
Msg-id b056baa5-aace-4e83-928d-dc669914c16b@cloud.gatewaynet.com
Whole thread Raw
In response to Re: postgresql FDW vs dblink for DDL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Στις 9/9/24 18:40, ο/η Tom Lane έγραψε:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 9/9/24 03:24, Achilleas Mantzios - cloud wrote:
>>> And the thing is that this creation via DDL is inside our design.
>>> Certain users create some backup tables of the public data in their own
>>> schema (via our app), then do some manipulations on the public data,
>>> then restore to the public or merge with the backups. When done, those
>>> backup tables are dropped. So the DDL is inside the app. And the
>>> question was if dblink is my only option, in the sense of doing this in
>>> a somewhat elegant manner. (and not resort to scripts, etc)
>> My sense is yes, if you want to encapsulate all of this within the
>> database/app you will need to use dblink.
> postgres_fdw certainly can't do it, nor any other FDW -- the FDW APIs
> simply don't cover issuance of DDL.  If you don't like dblink, you
> could consider writing code within plperlu or plpythonu or another
> "untrusted" PL, making use of whatever Postgres client library exists
> within that PL's ecosystem to connect to the remote server.  It's also
> possible that there's some third-party extension that overlaps
> dblink's functionality.  dblink sure seems like the path of least
> resistance, though.
Thank you Tom and Adrian.
>
>             regards, tom lane

-- 
Achilleas Mantzios
  IT DEV - HEAD
  IT DEPT
  Dynacom Tankers Mgmt (as agents only)




pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Clarify this MERGE warning? "Only columns from the target table that attempt to match data_source rows should appear in join_condition."
Next
From: Laurenz Albe
Date:
Subject: Re: Strange permission effect depending on DEFERRABILITY