On Wed, 9 Oct 2024, 21:22 Ashutosh Bapat, <ashutosh.bapat....@gmail.com> wrote:
> On Wed, Oct 9, 2024 at 4:22 AM Julien Rouhaud <rjuju...@gmail.com> wrote: > > > > On Wed, Oct 9, 2024 at 12:40 AM Ashutosh Bapat > > <ashutosh.bapat....@gmail.com> wrote: > > > > > > On Tue, Oct 8, 2024 at 7:57 PM Julien Rouhaud <rjuju...@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). >
