Re: [HACKERS] 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(at)joeconway(dot)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(at)joeconway(dot)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(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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

Doc patch attached for IS OF. Please apply.

Thanks,

Joe

> ---------------------------------------------------------------------------
>
> 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
>>

Joe Conway writes:

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

I suggest I should not be documented until it's fixed.

> Doc patch attached for IS OF. Please apply.

That is not the right place for it. IS OF is an operator, not an SQL
command.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:
> I suggest I should not be documented until it's fixed.
>
>>Doc patch attached for IS OF. Please apply.
>
> That is not the right place for it. IS OF is an operator, not an SQL
> command.
>

OK. If the attached patch is acceptable/applied, I'll fix and resend the
doc patch.

Joe

Joe Conway wrote:
> Peter Eisentraut wrote:
>> I suggest I should not be documented until it's fixed.
>>
>>> Doc patch attached for IS OF. Please apply.
>>
>> That is not the right place for it. IS OF is an operator, not an SQL
>> command.
>
> OK. If the attached patch is acceptable/applied, I'll fix and resend the
> doc patch.
>

Hmmm, looks like I was a bit quick on the draw:

regression=# select f1 is null, f2 is null, f3 is null from foo;
?column? | ?column? | ?column?
----------+----------+----------
f | t | f
t | f | f
f | f | t
(3 rows)

regression=# select f1 is of (int), f2 is of (text), f3 is of (float8)
from foo;
?column? | ?column? | ?column?
----------+----------+----------
t | t | t
t | t | t
t | t | t
(3 rows)

It worked correctly for constants, but not fields from a table :(

Back to the drawing board (suggestions welcomed).

Joe

Joe Conway <mail(at)joeconway(dot)com> writes:
> OK. If the attached patch is acceptable/applied, I'll fix and resend the
> doc patch.

I'm unconvinced that the parse-time-constant implementation Lockhart
started has anything whatever to do with the semantics the SQL99 spec
has in mind. In the first place, the spec seems to expect that the
lefthand side will actually be evaluated. Checking for a NULL constant
doesn't cover cases where the LHS returns NULL dynamically; let alone
cases where it would cause an error.

I also get the impression that they think the result may vary at
runtime. This is not totally impossible in Postgres, either --- you
could imagine that the LHS is a tuple from some inheritance tree, and
the IS OF query really amounts to asking which child table the tuple
came from.

Also, simple equality checks on the type OIDs don't cover the inheritance
cases (I think a child tuple should be said to be IS OF the tuple type
of its parent). And what about domains --- should we say a domain type
IS OF its base type?

regards, tom lane

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>
>>OK. If the attached patch is acceptable/applied, I'll fix and resend the
>>doc patch.
>
> I'm unconvinced that the parse-time-constant implementation Lockhart
> started has anything whatever to do with the semantics the SQL99 spec
> has in mind.

Yeah - I've realized this is quite a bit harder than it seemed on the
surface. However it is still useful, as is, when working with
polymorphic functions.

So do we rip it out, leave it undocumented, or document it including the
deviation from spec?

Joe

Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> I'm unconvinced that the parse-time-constant implementation Lockhart
>> started has anything whatever to do with the semantics the SQL99 spec
>> has in mind.

> Yeah - I've realized this is quite a bit harder than it seemed on the
> surface. However it is still useful, as is, when working with
> polymorphic functions.

In fact you could argue that our current behavior is *more* useful than
what the spec says for polymorphics. You would not want the special
case for NULLs, in most cases, I'd think. NULLs have perfectly well
defined datatype.

However, it troubles me to be using a spec-defined syntax for a behavior
that is not standard. I'd prefer to change the syntax if we are going
to keep the behavior. That probably puts it in the "too late for 7.4"
category. So I'm inclined to follow the path of leaving it undocumented
for now, implementing a new syntax in 7.5, and documenting it under that
syntax then.

regards, tom lane

Tom Lane wrote:
> In fact you could argue that our current behavior is *more* useful than
> what the spec says for polymorphics. You would not want the special
> case for NULLs, in most cases, I'd think. NULLs have perfectly well
> defined datatype.

That's actually exactly what I was thinking.

> However, it troubles me to be using a spec-defined syntax for a behavior
> that is not standard. I'd prefer to change the syntax if we are going
> to keep the behavior. That probably puts it in the "too late for 7.4"
> category. So I'm inclined to follow the path of leaving it undocumented
> for now, implementing a new syntax in 7.5, and documenting it under that
> syntax then.
>

Sounds good to me.

Thanks,

Joe