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

Re: reloptions with a "namespace"

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reloptions with a "namespace"
Date: 2009-01-30 15:59:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:

> > Okay, so I've changed things so that the transformRelOptions' caller is
> > now in charge of passing an array of valid option namespaces.  This is
> > working A-OK.  I'm now going to figure out appropriate pg_dump support
> > and commit as soon as possible.
> > 
> I don't like the spreading validnsps' approach. Isn't there a way to
> centralize those variables in one place, i.e., reloption.h ? Also, remove an
> obsolete comment about toast tables at reloption.h.

No, that doesn't work, because we don't know centrally what's the
allowed list of namespaces.  In fact that's precisely the problem: for
example, there's no point in having a "toast" namespace for index
reloptions.  And for a user-defined access method, we don't know what
the valid namespaces are.  Of course, the easiest way is to just state
that there are no valid namespaces other than NULL, and only allow
"toast" for heap, but I think that's not thinking far enough ahead.

The other option I considered was to have another AM entry point that
returns the list of valid namespaces, but that seems to be way overkill,
particularly considering that the current arrays are all NULL.

Alvaro Herrera       
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"

In response to

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2009-01-30 16:01:53
Subject: Re: using composite types in insert/update
Previous:From: Zdenek KotalaDate: 2009-01-30 15:51:42
Subject: Re: [PATCH] Space reservation v02

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