Skip site navigation (1) Skip section navigation (2)

Re: and it's not a bunny rabbit, either

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: and it's not a bunny rabbit, either
Date: 2010-12-29 19:29:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> The existing comments mention that callers must check that the return
> value is not a view, if they care.  So if there is currently a single
> coherent definition for what heap_open is supposed to do, it's clearly
> NOT the one Heikki proposes.  My guess is that reality is closer to
> your theory of "what got cut-and-pasted".

Well, reality is that in the beginning there was heap_open and
index_open, and nothing else.  And there weren't views, so basically
those two functions covered all the interesting types of relations.
We got to the current state of affairs by a series of whatever were the
least invasive code changes at the time; nobody's ever taken a step
back and tried to define what "heap_open" ought to allow from the
standpoint of first principles.

In practice I think it would make sense if heap_open accepts all
relation types on which you can potentially do either a heapscan or
indexscan (offhand those should be the same set of relkinds, I think;
so this is the same in effect as Heikki's proposal, but phrased
differently).  So it would have to start rejecting views, and we'd need
to go looking for the consequences of that.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-12-29 19:42:08
Subject: Re: and it's not a bunny rabbit, either
Previous:From: David FetterDate: 2010-12-29 19:26:48
Subject: Re: "writable CTEs"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group