Re: reloptions with a "namespace" - Mailing list pgsql-hackers

From Euler Taveira de Oliveira
Subject Re: reloptions with a "namespace"
Date
Msg-id 49826AA3.8020607@timbira.com
Whole thread Raw
In response to Re: reloptions with a "namespace"  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: reloptions with a "namespace"  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: reloptions with a "namespace"  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Alvaro Herrera escreveu:
> Alvaro Herrera wrote:
>> Euler Taveira de Oliveira wrote:
>>> Alvaro Herrera escreveu:
>>>> I wasn't sure of the best place to add a check.  I have added it to
>>>> transformRelOptions; I am not entirely comfortable with it, because it
>>>> works, but it still allows this:
>>>>
>>> IMHO it's the appropriate place.
>> I think the best place would be parseRelOptions.  The problem is that
>> transformRelOptions does not apply any semantics to the values it's
>> parsing; it doesn't know about the relopt_kind for example.  That stuff
>> is only known by parseRelOptions, but when the options reach that point,
>> they have already lost the namespace (due to transformRelOptions).
> 
> 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.


--  Euler Taveira de Oliveira http://www.timbira.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Should IS DISTINCT FROM work with ANY()?
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Space reservation v02