I agree with the SQL-92 function option should eb included as the base set of supported functions. How many of our supported database are SQL-92? Obviously that will workout when the work is being done.
I do like the idea of the extended syntax Gavin suggested but do question whether we need the extra complexity (though its hidden in the parser and only has to swap a few tokens[which is not always easy]). The Dialects support function signatures now and its common to SQL syntax so I would stay with that. Yes the alias would be a small extension on the current lookup mechanism in place now. Not difficult for the select clause since its basicly there, harder for the where clause since its a pure pass through. The dialect could provide a hook to provide the native name if passed the HQL name so in the unusual case where the function is non SQL-92 and the developer needs to use it in the where clause they can get the native name to use in the query string. This might do while the parser is upgraded. --David., ----- Original Message ----- From: "Les A. Hazlewood" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 18, 2003 4:05 AM Subject: Re: [Hibernate] Re: AST parser for HQL > > How about we get a list of ANSI-standard SQL functions and portably > > support those and those only (I don't think there are many of them). > > This makes a lot of sense. However, what if something so commonly used (like a > current_timestamp() function) is not part of the ANSI standard (assuming ANSI > SQL-92)? Would you make exceptions for that? > > I like the query substitution feature, but that requires effort on part of the > developer for even the most common tokens. I certainly agree that feature is > valuable for the occasional weird tokens a user may need. But highly common > substitutions that are supported by all rdmbs implementions should naturally be > part of the corresponding Dialect. > > Thinking out loud here, but for aliases for commonly used SQL functions/tokens, > wouldn't it be good to define them as part of the dialect via an internal lookup > table? These HQL standard aliases could also be prefixed with a hql identifier > to make it easy to signify when substitution should occur (and would be used as > the key in the Dialect's lookup table). > > (stupid example...returns everything...but you get the idea): > from MyClass obj where obj.creationTime < hql:now > > examples: > hql:current_date > hql:current_time > hql:current_timestamp or hql:now > > or you could ignore this approach completely and just use a function signature > itself as the token for lookup: > > current_date() > current_time() > current_timestamp() or now() > > although it seems logical to me that the first approach would be easier for a > lexical analyzer to handle. > > Just pondering... > > Cheers, > > Les > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
