[Fwd: OO Patch] - Mailing list pgsql-hackers

Peter Eisentraut wrote:
>
> Chris Bitmead writes:
>
> > > That also goes for the various ALTER TABLE [ONLY]
> > > syntax additions. If I add a row to A only then B is no longer a subtable
> > > of A.
> >
> > I agree that the alter table only is crazy, but the functionality was
> > there before and I didn't want to be the one to take it out. But if
> > someone does I can't imagine I'd object.
>
> Okay, I think I see what you're getting at. The "ONLY" syntax on DELETE,
> UPDATE, and ALTER TABLE would provide an entry point for the current,
> broken behaviour, for those who need it (though it's not really backwards
> compatibility per se).

That is absolutely NOT what I'm saying. In the ALTER TABLE case, yes it
is brain-dead. For UPDATE and DELETE it is absolutely correct, and
useful, not to mention absolutely essential.

> What I was also
> wondering about were these things such as the "virtual" IDENTITY field
> that was proposed, the `SELECT **' syntax (bad idea, IMO),

Ok, I can see we're going to rehash this yet again. Why is it a bad idea
(considering that every ODBMS on the planet does this)?

> and the notion
> that a query could return different types of rows when reading from an
> inheritance structure (a worse idea, IMO).

Please go out and use an ODBMS. I'm happy to discuss this, but even
Tom, who was at first against this understood after the last round.

> I didn't know whether the patch
> touched that. (I think now that it doesn't.)

It doesn't but a future patch hopefully will.Peter Eisentraut wrote:
>
> Chris Bitmead writes:
>
> > > That also goes for the various ALTER TABLE [ONLY]
> > > syntax additions. If I add a row to A only then B is no longer a subtable
> > > of A.
> >
> > I agree that the alter table only is crazy, but the functionality was
> > there before and I didn't want to be the one to take it out. But if
> > someone does I can't imagine I'd object.
>
> Okay, I think I see what you're getting at. The "ONLY" syntax on DELETE,
> UPDATE, and ALTER TABLE would provide an entry point for the current,
> broken behaviour, for those who need it (though it's not really backwards
> compatibility per se).

That is absolutely NOT what I'm saying. In the ALTER TABLE case, yes it
is brain-dead. For UPDATE and DELETE it is absolutely correct, and
useful, not to mention absolutely essential.

> What I was also
> wondering about were these things such as the "virtual" IDENTITY field
> that was proposed, the `SELECT **' syntax (bad idea, IMO),

Ok, I can see we're going to rehash this yet again. Why is it a bad idea
(considering that every ODBMS on the planet does this)?

> and the notion
> that a query could return different types of rows when reading from an
> inheritance structure (a worse idea, IMO).

Please go out and use an ODBMS. I'm happy to answer questions, but even
Tom, who was at first against this understood after the last round.

> I didn't know whether the patch
> touched that. (I think now that it doesn't.)

It doesn't but a future patch hopefully will.