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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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 21:04:05
Message-ID: AANLkTi=gbTKE8ncT06brk3gTkUd3-zShew9YYYQJmMSo@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-12-29 21:12:20
Subject: Re: pg_primary_conninfo
Previous:From: Simon RiggsDate: 2010-12-29 20:58:18
Subject: Re: small table left outer join big table

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