Обсуждение: Re: [HACKERS] crash on new system views

Поиск
Список
Период
Сортировка

Re: [HACKERS] crash on new system views

От
Andreas Zeugswetter
Дата:
> > > > The odd (maybe not?) thing is that views appear to have
> > > > a NULL oid for all tuples.
> > >
> > > This has always been the case.  Views don't have oid.
> > >
> >
> > OK, so we shouldn't be able to select a column called oid from
> > any view?
>
> That's an interesting question.  Do we disallow the query?  Comments?

I guess it would be nice if views could show the original oid for all non join or single table views.

Andreas




Re: [HACKERS] crash on new system views

От
The Hermit Hacker
Дата:
On Wed, 16 Sep 1998, Andreas Zeugswetter wrote:

>
> > > > > The odd (maybe not?) thing is that views appear to have
> > > > > a NULL oid for all tuples.
> > > >
> > > > This has always been the case.  Views don't have oid.
> > > >
> > >
> > > OK, so we shouldn't be able to select a column called oid from
> > > any view?
> >
> > That's an interesting question.  Do we disallow the query?  Comments?
>
> I guess it would be nice if views could show the original oid for all
> non join or single table views.

    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"...



Re: [HACKERS] crash on new system views

От
jwieck@debis.com (Jan Wieck)
Дата:
>    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) #