> IMHO, then the oid should be included as part of the view
> definition itself...even on a join operation, having the OID might be
> useful...consider a case where you have a join of two tables such that the
> select is something like:
>
> select a.oid,a.field,b.field where a.field=b.field;
>
> Having a.oid means that later I can just do:
>
> select * from <view> where oid = <oid#>;
>
> But I think the person setting up the view should be the one
> explicitly including the oid value, not the system "guessing"...
This is true. Especially if we look a bit ahead for functions
returning tuple sets, it might be possible in the future to
have a view that calls a functions to retrieve the data. But
this time all the data could be computed at runtime and there
is absolutely no OID the system can guess.
So if there should be one in another case, the creator of the
view must specify it. It must have a different name than oid
but I think this forces the creator to choose a name from
which the user can guess which oid it is in a join view.
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) #
