Added to TODO:
* Add ALTER DOMAIN, AGGREGATE, CONVERSION, SEQUENCE ... OWNER TO
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >
> >
> >>But should the CR
> 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
> 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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP
> DOMAIN be able to drop a type?
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
> reaso
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 would
> > 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... Pe
Tom Lane wrote:
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP
DOMAIN be able to drop a type?
Don't care much about either of those; the current state of
affairs is fine with me.
What happens in the future
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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 r
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> 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 inde
Peter Eisentraut <[EMAIL PROTECTED]> 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.
Tom Lane writes:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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
---(end of broadcast)
13 matches
Mail list logo
