Re: [HACKERS] It would be nice if this could be fixed...

From: jwieck(at)debis(dot)com (Jan Wieck)
To: scrappy(at)hub(dot)org (The Hermit Hacker)
Cc: chris(dot)bitmead(at)bigfoot(dot)com, pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] It would be nice if this could be fixed...
Date: 1999-04-26 14:54:11
Message-ID: m10bmlv-000EBYC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-04-26 14:54:55 Re: [HACKERS] Re: ERROR: index_rescan: invalid amrescan regproc ???
Previous Message The Hermit Hacker 1999-04-26 14:38:05 Re: [HACKERS] It would be nice if this could be fixed...