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

Redundant statements (was: Re: column STATISTICS lost)

From: Erwin Brandstetter <brandstetter(at)falter(dot)at>
To: guillaume(at)lelarge(dot)info
Cc: dpage(at)pgadmin(dot)org, pgadmin-hackers(at)postgresql(dot)org
Subject: Redundant statements (was: Re: column STATISTICS lost)
Date: 2010-04-28 17:16:49
Message-ID: 4BD86D81.8040306@falter.at (view raw or flat)
Thread:
Lists: pgadmin-hackers
Aloha!

I am testing Guillaume's version of pgadmin3.exe from Apr. 17.

The fix below is included and it seems to fix the problem just fine. 
However, as a side effect (?) there is now a redundant statement for 
each and every column:
     ALTER TABLE foo ALTER COLUMN bar SET STORAGE PLAIN;
or
     ALTER TABLE foo ALTER COLUMN baz SET STORAGE EXTENDED;

I think those statements should only be included, if the storage type 
differs from the default setting - like "SET STATISTICS" is handled now.
It is pretty noisy as it is now.

On a side note: I would handle "WITH (OIDS=FALSE)" for table definitions 
likewise: only print it, if it differs from the default setting.


Regards
Erwin


On 03.04.2010 11:46, guillaume(at)lelarge(dot)info wrote:
> Le 03/04/2010 11:19, Dave Page a écrit :
>    
>> On Sat, Apr 3, 2010 at 4:01 AM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info>  wrote:
>>      
>>> OK, I have a patch (attached) that seems to work. It adds some
>>> functions, and I'm not sure I should push this into the 1.10 branch.
>>> What do you guys think about this? only in trunk or in trunk and in the
>>> 1.10 branch?
>>>        
>> Seems like a bug fix to me, so I say 1.10.
>>
>>      
> OK, commited to both branches.
>
> Thanks.
>    

In response to

Responses

pgadmin-hackers by date

Next:From: Erwin BrandstetterDate: 2010-04-29 12:15:44
Subject: Re: Redundant statements
Previous:From: pgAdmin TracDate: 2010-04-28 13:03:44
Subject: Re: [pgAdmin III] #175: Column properties: uncalled attempt to "change" array data types

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