Marc G. Fournier wrote:
>
> 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...
Not exactly, because in his example there is only one table
used in the view. But I wonder what an OID from a view might
be good for? Under normal conditions, the OID is only good to
UPDATE/DELETE something that was first SELECTed and later
qualified by the application. But this is BAD design,
because any system attribute is DB specific and leads to
application portability problems. In any case, the primary
key should be used instead of a DB specific row identifier.
So the need of OID tells IMHO some insufficient database
layout.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
