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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers