Thread

Re: FOREIGN TABLE and IDENTITY columns

Julien Rouhaud <rjuju123@gmail.com> — 2024-10-09T13:31:05Z

On Wed, 9 Oct 2024, 21:22 Ashutosh Bapat, <ashutosh.bapat.oss@gmail.com>
wrote:

> On Wed, Oct 9, 2024 at 4:22 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > On Wed, Oct 9, 2024 at 12:40 AM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Tue, Oct 8, 2024 at 7:57 PM Julien Rouhaud <rjuju123@gmail.com>
> wrote:
> > > >
> > >
> > > The rows inserted/udpated on the foreign server won't honour the local
> > > IDENTITY constraint. Maybe that's why we don't want to support
> > > identity column in foreign tables. If all it is expected to do is add
> > > a monotonically increasing value, probably a DEFAULT value of
> > > nextval() would suffice.
> >
> > What if there is no local IDENTITY constraint, is that an unsupported
> scenario?
>
> Do you mean there's no local IDENTITY constraint but there's a remote
> one?


yes. after all the identity clause is supposed to be the standard way to
write it, and I don't see why having a relation only written through
foreign table(s) wouldn't be that unacceptable.

The documentation doesn't explicitly mention this. But it would
> be good to test how that works, esp if somebody tries to INSERT a row
> from local server with a value specified for an IDENTITY column.
>

I'm still waiting for an actual answer to whether the identity syntax is
supposed to be supported or not. I don't really see the point wasting time
testing that scenario and a bunch of others if someone shows up tomorrow to
say it's a mistake and we should be explicitly forbidding it (especially
since I won't be in front of a computer for a week or so).

>