On Wed, 2008-12-10 at 14:12 -0500, Tom Lane wrote:
> create domain d as int;
> create view v as select '-1'::d;
> alter domain d add constraint "c" check (value > 0);
> select * from v;
>
> Right now you get an error at the SELECT, but that seems a bit
> surprising. It's even more surprising that the CREATE still works if
> you made the constraint first. And a novice might reasonably wonder why
> the domain check is postponed when the underlying type's checks occur
> instantly --- for example, this fails outright:
> create view v as select 'z'::d;
>
> So this is all a bit odd to start with, and then on top of that we have
> the issue that the check timing changes if you put the domain inside a
> record.
>
> Comments?
>
Does the standard provide guidance here? I took a look, and it's
difficult to tell, because it uses words like "evaluation" (and I don't
think that a view is required to actually evaluate anything).
It also talks about deferrable and non-deferrable, which indicate that
the constraint should apply at insertion time.
Standard aside... To me, it seems reasonable that something like the
CREATE VIEW above should fail, because you're specifying a literal of
type "d" (invoking the type selector for "d" on a value representation
of unknown type), and it is invalid in the domain "d".
However, a similar construction:
create view v as select cast('-1'::int AS d);
seems slightly different to me, because the value already has a type,
and the exception is raised from the explicit cast. It's the same as if
it casted some variable "x" instead of '-1'::int, because variables
already have types.
Consider something like this:
create view v as select 1::int/0::int;
Here, I see division as a function that can raise an exception, similar
to how an explicit cast can raise an exception. There's no expectation
that the view will evaluate 1/0 at CREATE VIEW time, because 0 might be
some variable "x" (ranging over some underlying table) that can't
possibly be evaluated at view creation time.
In other words, I see casts as functions that may or may not raise an
exception during evaluation, and that should not be evaluated at view
creation time. However, I do not see type selectors
('representation'::type) as functions, because they do not have an
argument of a specific type. I think type selectors should be evaluated
at view creation time, because the value must become a variable at that
time.
Regards,Jeff Davis