Subject: Re[2]: Possible new key () function (Was: Re: [xsl] Finding t From: Steven.C.Kienle@xxxxxxxxxx Date: Tue, 9 Jan 2001 13:37:21 -0500 |
We should remember that early database technologies required keys to be explicitly used during data access. SQL improved things, but it still requires that someone define what keys are likely to be used (via CREATE INDEX statements/constraints). Perhaps this can be changed now, but I think a lot more thought would need to be put into it before a workable alternative could be designed. Steve ______________________________ Reply Separator _________________________________ Subject: RE: Possible new key() function (Was: Re: [xsl] Finding the Author: Kay Michael <Michael.Kay@xxxxxxx> at Internet-America Date: 09-01-2001 10:14 AM > > In this case xsl:key will know in advance about all possible > > operators and could build the indexes in an optimal way in order to > > guarantee most efficient key() performance. The more I listen to this discussion, the more convinced I am that SQL got it right and XSLT got it wrong: keys should be used implicitly, behind the scenes, when the optimizer decides and not when the user decides. Rather than having new variants on the key() function, we should do away with the function entirely. Mike Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] SAXON systemid() usage. , Kay Michael | Thread | [xsl] Executing an alternate templa, Adam Van Den Hoven |
Re: [xsl] cross document id idref p, Jeni Tennison | Date | [xsl] Executing an alternate templa, Adam Van Den Hoven |
Month |