On Sat, 17 Apr 1999, Chris Bitmead wrote:
>
> I'm not sure what you're getting at. Yep, you can include the oid field
> if you rename it, but it would be nice if you could leave it alone.
>
> A typical scenario is that you create some table and start using it.
> Then you find you need some derived field (like quantity*price AS total)
> or something. So you may rename say product table to productold, and
> create a product view that is SELECT *, quantity*price AS total from
> productold.
>
> The problem then arises if your code uses oid, because a view can't have
> a field called oid. I'm advocating that you be allowed to create views
> that have a field called oid to avoid this problem.
As D'Arcy did ask...which oid would you want used? The one from table a,
or from Table b? They are two distinctly different numbers...the VIEW
itself doesn't have an OID assigned to its rows, only the physical tables
themselves...
> > "D'Arcy J.M. Cain" wrote:
> >
> > Thus spake Chris Bitmead
> > > It would be much better if you could have an oid column in a view if you
> > > want. Like
> > > CREATE VIEW productv AS SELECT oid, * FROM product;
> > >
> > > But that's not allowed. Any reason why?
> >
> > Because the oid is not included in the view. Consider the following.
> >
> > CREATE VIEW c AS SELECT a1, a2, b1, b2 FROM a, b WHERE a_key = b_key;
> >
> > So which oid do you want, the one from table a or the one from table b?
> > You can, however, do this.
> >
> > CREATE VIEW c AS SELECT a.oid AS a_oid, b.oid AS b_oid, a1, a2, b1, b2
> > FROM a, b WHERE a_key = b_key;
> >
> > --
> > D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
> > http://www.druid.net/darcy/ | and a sheep voting on
> > +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
>
> --
> Chris Bitmead
> http://www.bigfoot.com/~chris.bitmead
> mailto:chris.bitmead@bigfoot.com
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
