[Monetdb-developers] Data type of the text() nodes
jens.teubner at in.tum.de
Mon Jun 4 22:31:56 CEST 2007
On Mon, Jun 04, 2007 at 10:17:10AM +0200, Peter Boncz wrote:
> For this reason my proposed fix is to use the function signature type
> *only* if it is a subtype of the runtime type (= if it is more
I don't understand this "fix" for two reasons:
-- Testing this direction seems odd. The dynamic type will usually be
a subtype of the static type (though this is not necessarily the
case, due to the difference between the `subtype' and the
-- Your "fix" only describes an `if' branch. What do you do in the
`else' branch (i.e., if the static type is not a subtype of the
> While the above probably fixes Jennie's issue, I do think there is a
> problem in pathfinder with function parameter promotion. This can
> surface when the typeswitch() is used inside the function body.
> Basically, when types are promoted, the runtime representation should
> be forced to reflect this. AFAIK this is not done in mps -- maybe the
> new type annotation system (in progress) handles this? With such a
> system in place, the runtime type would already be xs:string and the
> hack I propose above would not be needed.
Right. This is a design flaw in mps. Pathfinder's algebraic backend
will do these things correctly.
> As an aside, I also think that there is something wrong in pathfinder
> with type promotion in general comparisons. Specifically, while the
> spec says that in case of a comparision between untyped data and a
> numeric, the untyped should be cast to xs:double. Pathfinder seems to
> apply a direct cast to the specific numeric data type (e.g.
> xs:integer) instead.
> Example: <a t='1.1'/>/@t = 1
I think this is correctly handled in Pathfinder. See Section 4.5.2,
Paragraph "Normalization" in the XQuery Formal Semantics.
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259 Fax: +49 89 289-17263
-- `perlstyle' man page
More information about the developers-list