Thread: DROP TYPE/DROP DOMAIN

DROP TYPE/DROP DOMAIN

From
"Christopher Kings-Lynne"
Date:
I notice you can use the 'DROP TYPE' syntax to drop a domain.  Should that
be allowed?

Chris



Re: DROP TYPE/DROP DOMAIN

From
Tom Lane
Date:
"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


Re: DROP TYPE/DROP DOMAIN

From
Peter Eisentraut
Date:
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


Re: DROP TYPE/DROP DOMAIN

From
Tom Lane
Date:
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


Re: DROP TYPE/DROP DOMAIN

From
Peter Eisentraut
Date:
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


Re: DROP TYPE/DROP DOMAIN

From
Tom Lane
Date:
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


Re: DROP TYPE/DROP DOMAIN

From
Bruce Momjian
Date:
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
 


Re: DROP TYPE/DROP DOMAIN

From
"Christopher Kings-Lynne"
Date:
> > 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



Re: DROP TYPE/DROP DOMAIN

From
"Christopher Kings-Lynne"
Date:
> 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



Re: DROP TYPE/DROP DOMAIN

From
Tom Lane
Date:
"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


Re: DROP TYPE/DROP DOMAIN

From
"Christopher Kings-Lynne"
Date:
> 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



Re: DROP TYPE/DROP DOMAIN

From
Tom Lane
Date:
"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


Re: DROP TYPE/DROP DOMAIN

From
Andreas Pflug
Date:
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



Re: DROP TYPE/DROP DOMAIN

From
Bruce Momjian
Date:
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