> -----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