Обсуждение: AW: Backend-internal SPI operations

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

AW: Backend-internal SPI operations

От
Zeugswetter Andreas SB
Дата:
>     The problem here is, that the relkind  must  change  at  rule
>     creation/drop  time.  Fortunately rules on SELECT are totally
>     restricted to VIEW's since 6.4, and I don't see any reason to
>     change this.

I don't see why a real view should still be createable by the old
create table then create rule way. Then the relkind would never 
need to change. The only place that would need correction is 
pg_dump to dump create view statements.

Imho we should not limit select rules to views by design.
With a different relkind for views this is not necessary anyway.

Andreas


Re: AW: Backend-internal SPI operations

От
Tom Lane
Дата:
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> I don't see why a real view should still be createable by the old
> create table then create rule way.

Because we'll need to be able to read dump files created by existing
versions of pg_dump.  If we don't cope with CREATE TABLE + CREATE RULE
then restored-from-dump views won't really be views and will act
differently from freshly created views.  Avoiding the resulting
support headaches is worth a little bit of ugliness in the code.
        regards, tom lane


Re: AW: Backend-internal SPI operations

От
"Ross J. Reedstrom"
Дата:
On Thu, Aug 31, 2000 at 10:19:36AM -0400, Tom Lane wrote:
> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> > I don't see why a real view should still be createable by the old
> > create table then create rule way.
> 
> Because we'll need to be able to read dump files created by existing
> versions of pg_dump.  If we don't cope with CREATE TABLE + CREATE RULE
> then restored-from-dump views won't really be views and will act
> differently from freshly created views.  Avoiding the resulting
> support headaches is worth a little bit of ugliness in the code.
> 

So, this'd be a one release only sort of hack, for compatability? It'd
be born deprecated? Hmm, is someone keeping track of all the features
that have been deprecated, so they can be stripped out later?

Also, sounds like something for Lamar's future pg_upgrade rewrite.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005