Обсуждение: IS OF

While messing around in gram.y I came across a production like this:

| a_expr IS OF '(' type_list ')' %prec IS
{  $$ = (Node *) makeSimpleA_Expr(AEXPR_OF, "=", $1, (Node *) $5);
}
| a_expr IS NOT OF '(' type_list ')' %prec IS
{  $$ = (Node *) makeSimpleA_Expr(AEXPR_OF, "!=", $1, (Node *) $6);
}

Works like so:

regression=# select array[1,1.2] is of (numeric[]); ?column?
---------- t
(1 row)

Pretty handy! But I couldn't find it documented anywhere -- is it?

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> Pretty handy! But I couldn't find it documented anywhere -- is it?

I think Thomas did that in one of his last batches of changes, and then
disappeared without adding the documentation.  Feel free to contribute
some.

I believe it is supposed to be a SQL99 feature, so you might see if the
spec sheds any light ...
        regards, tom lane

On Sat, 22 Mar 2003, Tom Lane wrote:

> Joe Conway <mail@joeconway.com> writes:
> > Pretty handy! But I couldn't find it documented anywhere -- is it?
> 
> I think Thomas did that in one of his last batches of changes, and then
> disappeared without adding the documentation.  Feel free to contribute
> some.
> 
> I believe it is supposed to be a SQL99 feature, so you might see if the
> spec sheds any light ...

8.14 <type predicate> to be exact.

Gavin

Gavin Sherry wrote:
> 
> 8.14 <type predicate> to be exact.
> 

8.18 in SQL200x. I don't think the current implementation quite meets 
the spec however:

regression=# select f2 is null, f2 is of(int) from bar; ?column? | ?column?
----------+---------- f        | t t        | t
(2 rows)

If I read the spec correctly, the null value should return null, not 't' 
in the above.

General Rules
1) Let V be the result of evaluating the <row value predicand>.
2) Let ST be the set consisting of every type that is either some   exclusively specified type, or a subtype of some
inclusively  specified type.
 
3) Let TPR be the result of evaluating the <type predicate>.

Case:
a) If V is the null value, then TPR is Unknown.
b) If the most specific type of V is a member of ST, then TPR is True .
c) Otherwise, TPR is False

Probably best not to document it until someone gets around to fixing it 
-- I can do it, but not for the next few weeks at least.

Joe

Can someone suggest where to document IS OF, and either document it's
non-standard behavior or supply patch?

---------------------------------------------------------------------------

Joe Conway wrote:
> Gavin Sherry wrote:
> > 
> > 8.14 <type predicate> to be exact.
> > 
> 
> 8.18 in SQL200x. I don't think the current implementation quite meets 
> the spec however:
> 
> regression=# select f2 is null, f2 is of(int) from bar;
>   ?column? | ?column?
> ----------+----------
>   f        | t
>   t        | t
> (2 rows)
> 
> If I read the spec correctly, the null value should return null, not 't' 
> in the above.
> 
> General Rules
> 1) Let V be the result of evaluating the <row value predicand>.
> 2) Let ST be the set consisting of every type that is either some
>     exclusively specified type, or a subtype of some inclusively
>     specified type.
> 3) Let TPR be the result of evaluating the <type predicate>.
> 
> Case:
> a) If V is the null value, then TPR is Unknown.
> b) If the most specific type of V is a member of ST, then TPR is True .
> c) Otherwise, TPR is False
> 
> Probably best not to document it until someone gets around to fixing it 
> -- I can do it, but not for the next few weeks at least.
> 
> Joe
> 
> 
> ---------------------------(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
 

Bruce Momjian wrote:
> Can someone suggest where to document IS OF, and either document it's
> non-standard behavior or supply patch?
> 

I can document the current behavior, but I'll wait until after the 
feature freeze.

Joe