Re: Query on postgres_fdw extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Swathi P <swathi(dot)bluepearl(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Query on postgres_fdw extension
Date: 2021-05-14 14:53:12
Message-ID: 1883853.1621003992@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

[ removing -bugs ]

Swathi P <swathi(dot)bluepearl(at)gmail(dot)com> writes:
> Hence we decided to have the coordinator nodes as stateless and hence
> declared the column with no serial/sequence. Let me know if this makes
> sense.

Attaching serial-sequence defaults on both sides would certainly not
work very well, because the sequences wouldn't stay in sync.

Unfortunately, postgres_fdw just doesn't have a good way right now
to make use of dynamically-generated defaults at the remote server.
If you leave out a column in your INSERT, it's going to compute
and send the locally-defined default (which is just null in this
case), so the remote's default expression is never used.

I remember that we spent a great deal of effort in postgres_fdw's
early days, trying to find a way that we could use the remote's
defaults in cases like this. But everything we tried ended up
causing horrible semantic inconsistencies, so we ended up with
the always-use-the-local-default approach. There was some feeling
that maybe this could be revisited later, but no one's done so.

One conceivable workaround is to do your insertions through a
foreign table that doesn't even have the serial column, so that
the INSERT command received by the remote server lacks that
column and the default gets applied. Probably too messy though.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-05-14 14:57:30 Re: BUG #16833: postgresql 13.1 process crash every hour
Previous Message Bharath Rupireddy 2021-05-14 13:54:56 Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)

Browse pgsql-general by date

  From Date Subject
Next Message Bharath Rupireddy 2021-05-14 15:10:52 Re: Query on postgres_fdw extension
Previous Message David G. Johnston 2021-05-14 14:49:48 Re: Same column names in a subresult table