Re: [PATCHES] [HACKERS] IS OF
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 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 . 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 . 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 Index: doc/src/sgml/reference.sgml === RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/reference.sgml,v retrieving revision 1.45 diff -c -r1.45 reference.sgml *** doc/src/sgml/reference.sgml 27 Jun 2003 14:45:25 - 1.45 --- doc/src/sgml/reference.sgml 8 Aug 2003 05:16:26 - *** *** 108,113 --- 108,114 &fetch; &grant; &insert; +&isof; &listen; &load; &lock; Index: doc/src/sgml/ref/allfiles.sgml === RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/ref/allfiles.sgml,v retrieving revision 1.54 diff -c -r1.54 allfiles.sgml *** doc/src/sgml/ref/allfiles.sgml 27 Jun 2003 14:45:25 - 1.54 --- doc/src/sgml/ref/allfiles.sgml 8 Aug 2003 04:45:35 - *** *** 76,81 --- 76,82 + Index: doc/src/sgml/ref/isof.sgml === RCS file: doc/src/sgml/ref/isof.sgml diff -N doc/src/sgml/ref/isof.sgml *** /dev/null 1 Jan 1970 00:00:00 - --- doc/src/sgml/ref/isof.sgml 8 Aug 2003 05:20:46 - *** *** 0 --- 1,84 + + + IS OF + SQL - Language Statements + + + + IS OF + specify a type test + + + + + expression IS [ NOT ] OF ( typename[, ... ] ) + + + + + Description + + +This command allows an expression to be checked against a list +of data types. It returns TRUE if any data type in the list matches +that of the expression, +FALSE otherwise. + + + + + + Examples + + regression=# SELECT 1::int4 IS OF (int4, int8); + ?column? + -- + t + (1 row) + + regression=# SELECT 1::int4 IS OF (text); + ?column? + -- + f + (1 row) + + regression=# SELECT ARRAY['a'] IS OF (text[]); + ?column? + -- + t + (1 row) + + + + + Compatibility + + +The SQL standard specifies that IS OF +must result in UNKNOWN if +expression is +NULL. The PostgreSQL +implementation results in TRUE or FALSE +as appropriate based on the data type assigned by the planner. +Otherwise, this command is fully conforming. + + + + + + ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] IS OF
Tom Lane wrote: Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] IS OF
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
Index: src/backend/parser/parse_expr.c
===
RCS file: /opt/src/cvs/pgsql-server/src/backend/parser/parse_expr.c,v
retrieving revision 1.160
diff -c -r1.160 parse_expr.c
*** src/backend/parser/parse_expr.c 4 Aug 2003 02:40:01 - 1.160
--- src/backend/parser/parse_expr.c 8 Aug 2003 21:53:25 -
***
*** 45,51
static Node *transformColumnRef(ParseState *pstate, ColumnRef *cref);
static Node *transformIndirection(ParseState *pstate, Node *basenode,
List *indirection);
!
/*
* Initialize for parsing a new query.
--- 44,50
static Node *transformColumnRef(ParseState *pstate, ColumnRef *cref);
static Node *transformIndirection(ParseState *pstate, Node *basenode,
List *indirection);
! static bool exprIsNullConstantTypeCast(Node *arg);
/*
* Initialize for parsing a new query.
***
*** 394,421
Node *lexpr =
transformExpr(pstate,
a->lexpr);
- ltype = exprType(lexpr);
- foreach(telem, (List *)
a->rexpr)
- {
- rtype =
LookupTypeName(lfirst(telem));
- matched = (rtype ==
ltype);
- if (matched)
- break;
- }
-
- /*
-* Expect two forms: equals or
not equals.
-* Flip the sense of the
result for not
-* equals.
-*/
- if
(strcmp(strVal(lfirst(a->name)), "!=") == 0)
- matched = (!matched);
-
n = makeNode(A_Const);
n->val.type = T_String;
- n->val.val.str = (matched ?
"t" : "f");
n->typename =
SystemTypeName("bool");
result = transformExpr(pstate,
(Node *) n);
}
break;
--- 393,426
Node *lexpr =
transformExpr(pstate,
a->lexpr);
n = makeNode(A_Const);
n->val.type = T_String;
n->typename =
SystemTypeName("bool");
+ if
(exprIsNullConstantTypeCast(a->lexpr))
+ n->val.val.str = "f";
+ else
+ {
+ ltype =
exprType(lexpr);
+ foreach(telem, (List
*) a->rexpr)
+ {
+ rtype =
LookupTypeName(lfirst(telem));
+ matched =
(rtype == ltype);
+ if (matched)
+ break;
+ }
+
+ /*
+* Expect two fo
Re: [PATCHES] [HACKERS] IS OF
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] IS OF
Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] IS OF
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] IS OF
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] IS OF
Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
