Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT

Le 18 juil. 09 à 20:55, Robert Haas a écrit :
> that indicate the base rev of the patch.  In fact that rev is BEFORE
> the one I based the patch on, which was
> 64b2da3f7778bc6fd3d213ceb9e73ff3b6e03890, and it actually applies OK
> up until 0e3abe7ec78a3d51032d684598f188b0b0304fe9, the commit
> immediately preceding the 8.4 pgindent run.

Robert told me on rrreviewers it's all whitespace stuff, which I could  
confirmed after having trained my eyes to recognize the pattern and  
mix and match whitespace and new column in the middle. Patch applied,  
I'll have to update the version check, but the following paste means  
I'm the one having to work on it now:
   Table "pg_catalog.pg_attribute"   Column     |   Type    | Modifiers
---------------+-----------+-----------
...
attstattarget | integer   | not null
attdistinct   | real      | not null
attlen        | smallint  | not null

> Hmm, I didn't know that (my man page doesn't contain that language).
> It looks like strtod() is more widely used in the existing source code
> than atof(), so I'll change it (atof() is however used in the
> floatVal() macro).

Considering I don't have an updated version when I start again, I'll  
have a try at it: don't rush into it yourself :)

>>  What about adding the following before the switch, to do like  
>> surrounding
>> code?
>>        Assert(IsA(newValue, Integer) || IsA(newValue, Float));
>
> Not a good plan.  In my experience, gcc doesn't like switch ()
> statements over enums that don't list all the values, unless they have
> a default clause; it masterminds by giving you a warning that you've
> "inadvertently" left out some values.

Maybe this could still be a supplementary barrier for cassert builds  
in order to match existing code?
-- 
dim

I'm going to update the status of patch and resume work on it next week.