public inbox for [email protected]
help / color / mirror / Atom feedRe: postgresql FDW vs dblink for DDL
2+ messages / 2 participants
[nested] [flat]
* Re: postgresql FDW vs dblink for DDL
@ 2024-09-09 15:40 Tom Lane <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2024-09-09 15:40 UTC (permalink / raw)
To: Adrian Klaver <[email protected]>; +Cc: Achilleas Mantzios - cloud <[email protected]>; [email protected] <[email protected]>
Adrian Klaver <[email protected]> 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.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: postgresql FDW vs dblink for DDL
@ 2024-09-09 16:56 Achilleas Mantzios <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Achilleas Mantzios @ 2024-09-09 16:56 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Adrian Klaver <[email protected]>; +Cc: [email protected] <[email protected]>
Στις 9/9/24 18:40, ο/η Tom Lane έγραψε:
> Adrian Klaver <[email protected]> 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)
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-09-09 16:56 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-09 15:40 Re: postgresql FDW vs dblink for DDL Tom Lane <[email protected]>
2024-09-09 16:56 ` Achilleas Mantzios <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox