> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailtogadmin-hackers-owner@postgresql.org] On Behalf Of
> Bawer Dagdeviren
> Sent: 19 May 2006 12:15
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] Changing types without DROP...CASCADE
>
> Hi!

Hi,

> My name is Bawer Dagdeviren, I currently work as a developer
> for a small firm in Sweden, mainly creating web-applications
> in the dotNet-Framework.
> I'm new to this list and I have been using pgAdmin for some time now.
> It's a really good product, so I'd like to see some features
> added and generally help with development whenever I have
> time to spare.
>
> I'll start with a question:
> Have you guys thought about making it possible to alter a
> type definition (CREATE TYPE) without having to
> DROP...CASCADE on all stored procedures using that type? I
> have missed this feature too many times now that I would like
> to help implement it, or at least make the issue known if it isn't.
>
> Essentially what need to happen is a DROP...CASCADE of all
> functions using that type and then recreating them again,
> right? What do you think?

I think that this particular case is probably not that interesting to
most people (though that is not to say it shouldn't be done) - the more
common case is already on the TODO list as:

- Recreate views after column type change

Both are essentially the same problem, and as there may be more similar
cases that haven't yet been considered (or may only appear in future
releases of PostgreSQL), it seems to me that a relatively generic
mechanism for rebuilding dependent objects should be implemented. I
don't have time to look at this myself right now, but if you want to
please do, and feel free to post any questions you may have.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Dave Page wrote:
>
>
>> I think that this particular case is probably not that interesting to
>> most people (though that is not to say it shouldn't be done) - the more
>> common case is already on the TODO list as:
>>
>> - Recreate views after column type change
>>
>> Both are essentially the same problem, and as there may be more similar
>> cases that haven't yet been considered (or may only appear in future
>> releases of PostgreSQL), it seems to me that a relatively generic
>> mechanism for rebuilding dependent objects should be implemented. I
>> don't have time to look at this myself right now, but if you want to
>> please do, and feel free to post any questions you may have.
>>
>> Regards, Dave

Ok, Dave. I will start by looking around in the code-base and get to
know it better. Then I'll try my best to tackle the TODO-entry!

Best wishes,

Bawer

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match