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

On Wed, Dec 29, 2010 at 3:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
>>> 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.
>
>> This seems a very good idea, but I think we shouldn't let it sink the
>> current patch.
>
> No, but possibly regularizing what heap_open is defined to do would make
> Robert's patch simpler.

I think that any meaning we assign to heap_open is going to be 95%
arbitrary and of little practical help. There are at least six
different sets of object classes which to which a particular commands
or alter table subcommands can be legally applied: (1) tables only,
(2) views only, (3) tables and views, (4) tables and indexes, (5)
tables and composite types, (6) tables, views, and composite types.
Adding foreign tables promises to add several more combinations
immediately and likely more down the line; if we add materialized
views, that'll add a bunch more. There's not really any single
definition that's going to be a silver bullet. I think the best thing
to do might be to get RID of heap_open(rv) and always use
relation_openrv plus an appropriate relkind test.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company