RE: pg_depend - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: pg_depend
Date
Msg-id EKEJJICOHDIEMGPNIFIJMEEKEPAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: pg_depend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Reference name is needed not an object name,
> 
> Only if we want to support the notion that 
> drop-and-recreate-with-same-name
> means that references from other objects should now apply to the new
> object.  I do not think that that's really a good idea, at least not
> without a heck of a lot of compatibility checking.  It'd be way too easy
> to create cases where the properties of the new object do not match
> what the referring object expects.
> 

For example, we would process the following step to drop a
column.

select ....(all columns except a column) from a into b;
drop table a;
alter table b rename to a;

But we would lose all relelvant objects.

Though we may be able to solve this problem by implementing
*drop column* properly, we couldn't solve this kind of problems
at once. In fact neither *drop column* nor *cluster* is solved.
We could always have (at least) the second best way by
allowing drop-and-recreate-with-same-name revival.

> The majority of the cases I've heard about where this would be useful
> are for functions, and we could solve that a lot better with an ALTER
> FUNCTION command that allows changing the function body (but not the
> name, arguments, or result type).
> 
> BTW, name alone is not a good enough referent for functions... you'd
> have to store the argument types too.
> 

??? Isn't an entrypg_proc_relidthe oid of the functionpg_type_relidthe oid of an argument typethe name of the argument
type
made ?

regards,
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_depend
Next
From: Lamar Owen
Date:
Subject: Re: OID wraparound (was Re: pg_depend)