Обсуждение: DROP TYPE/DROP DOMAIN
I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that be allowed? Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that
> be allowed?
Why not? A domain *is* a type, by any reasonable test.
regards, tom lane
Tom Lane writes: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that > > be allowed? > > Why not? A domain *is* a type, by any reasonable test. According to that logic, a view is a table, but we still require DROP VIEW to drop a view. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Why not? A domain *is* a type, by any reasonable test.
> According to that logic, a view is a table, but we still require DROP VIEW
> to drop a view.
No, a view is not a table. Try putting an index or trigger on it.
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane writes: > >> Why not? A domain *is* a type, by any reasonable test. > > > According to that logic, a view is a table, but we still require DROP VIEW > > to drop a view. > > No, a view is not a table. Try putting an index or trigger on it. According to that logic, a domain is not a type. Try putting a check constraint on it. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> No, a view is not a table. Try putting an index or trigger on it.
> According to that logic, a domain is not a type. Try putting a check
> constraint on it.
But that's an additional feature, not a missing feature.
I think the reason we are restrictive about the comparable cases for
relations (pg_class entries) is that we use pg_class entries for a
number of things that users see as unrelated or only weakly related.
For example, indexes are not tables by any reasonable definition above
the implementation level; sequences are tables only as an artifact of
a particular implementation (which I think we'll someday have to abandon
BTW); composite types surely aren't tables. It would be surprising for
a composite type to be droppable by DROP TABLE. But domains *are*
types, both to the user and to the implementation, and so I see no
surprise factor in allowing DROP TYPE to work on them.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane writes: > >> No, a view is not a table. Try putting an index or trigger on it. > > > According to that logic, a domain is not a type. Try putting a check > > constraint on it. > > But that's an additional feature, not a missing feature. And added in 7.4: Add DOMAIN CHECK constraints (Rod) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > According to that logic, a view is a table, but we still require DROP VIEW > > to drop a view. > > No, a view is not a table. Try putting an index or trigger on it. It seems to me to be more correct that we make DROP TYPE not work on domains. I refer to the principle of least surprise... People EXPECT it to not work, therefore it shouldn't :) There exists a perfectly good other command (drop domain) that works, and you can't go alter type..add check(...) on a domain. Also, we don't want to encourage people to use commands that maybe we might remove in the future... Chris
> But that's an additional feature, not a missing feature. > > I think the reason we are restrictive about the comparable cases for > relations (pg_class entries) is that we use pg_class entries for a > number of things that users see as unrelated or only weakly related. > For example, indexes are not tables by any reasonable definition above > the implementation level; sequences are tables only as an artifact of > a particular implementation (which I think we'll someday have to abandon > BTW); composite types surely aren't tables. It would be surprising for > a composite type to be droppable by DROP TABLE. But domains *are* > types, both to the user and to the implementation, and so I see no > surprise factor in allowing DROP TYPE to work on them. Will DROP TYPE automatically handle dropping constraints and dependent columns properly? Will all its messages use the word 'domain' and not 'type'? I can't see any conceivable reason to allow this syntax to work! We are giving zero benefit for a non-zero cost... Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Will DROP TYPE automatically handle dropping constraints and dependent
> columns properly?
Sure. Once you get down to the dependency-chaser, a type is a type.
> Will all its messages use the word 'domain' and not
> 'type'?
No, but I wouldn't bet on DROP DOMAIN uniformly saying "domain" either.
It's the same code as soon as you get below the top-level command
routine (compare RemoveType and RemoveDomain).
> I can't see any conceivable reason to allow this syntax to work!
> We are giving zero benefit for a non-zero cost...
I'd state that exactly the other way around: testing for and rejecting
domains in DROP TYPE will take more code (okay, only a few lines, but
still more code) and I consider the benefit nil.
If you try to make every message in the system distinguish "type" from
"domain", then you are talking about a *lot* more code, for even less
benefit. Also there are places where you simply can't know which to
say --- should "type not found" be changed to "domain not found"?
regards, tom lane
> No, but I wouldn't bet on DROP DOMAIN uniformly saying "domain" either. > It's the same code as soon as you get below the top-level command > routine (compare RemoveType and RemoveDomain). > > > I can't see any conceivable reason to allow this syntax to work! > > We are giving zero benefit for a non-zero cost... > > I'd state that exactly the other way around: testing for and rejecting > domains in DROP TYPE will take more code (okay, only a few lines, but > still more code) and I consider the benefit nil. But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP DOMAIN be able to drop a type? What happens in the future if for some reason we need to add some special case to dropDomain() and the coder neglects to add it to dropType()? The benefit is reduced thinks to worry about when coding AFAIKS. Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP
> DOMAIN be able to drop a type?
<shrug> Don't care much about either of those; the current state of
affairs is fine with me.
> What happens in the future if for some
> reason we need to add some special case to dropDomain() and the coder
> neglects to add it to dropType()?
That would be a bug without regard for any of this discussion, because
both RemoveDomain and RemoveType are simply user interface routines;
they do no actual work. If someone put actual work into either, it'd
be wrong because it would not get done during a cascaded drop.
regards, tom lane
Tom Lane wrote: >"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > >>But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP >>DOMAIN be able to drop a type? >> >> > ><shrug> Don't care much about either of those; the current state of >affairs is fine with me. > > > >>What happens in the future if for some >>reason we need to add some special case to dropDomain() and the coder >>neglects to add it to dropType()? >> >> > >That would be a bug without regard for any of this discussion, because >both RemoveDomain and RemoveType are simply user interface routines; >they do no actual work. If someone put actual work into either, it'd >be wrong because it would not get done during a cascaded drop. > > > While implementing the new ALTER DOMAIN ... OWNER TO stuff, I found that there's no corresponding command for TYPE (and ALTER DOMAIN will reject a TYPE). IMHO this should go on TODO for symmetry reasons. And how about AGGREGATE, CONVERSION, SEQUENCE? (the latter can be changed by ALTER TABLE). Regards, Andreas
Added to TODO: * Add ALTER DOMAIN, AGGREGATE, CONVERSION, SEQUENCE ... OWNER TO --------------------------------------------------------------------------- Andreas Pflug wrote: > Tom Lane wrote: > > >"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > > > > >>But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP > >>DOMAIN be able to drop a type? > >> > >> > > > ><shrug> Don't care much about either of those; the current state of > >affairs is fine with me. > > > > > > > >>What happens in the future if for some > >>reason we need to add some special case to dropDomain() and the coder > >>neglects to add it to dropType()? > >> > >> > > > >That would be a bug without regard for any of this discussion, because > >both RemoveDomain and RemoveType are simply user interface routines; > >they do no actual work. If someone put actual work into either, it'd > >be wrong because it would not get done during a cascaded drop. > > > > > > > > While implementing the new ALTER DOMAIN ... OWNER TO stuff, I found that > there's no corresponding command for TYPE (and ALTER DOMAIN will reject > a TYPE). IMHO this should go on TODO for symmetry reasons. And how about > AGGREGATE, CONVERSION, SEQUENCE? (the latter can be changed by ALTER TABLE). > > > Regards, > Andreas > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073