From: Steve S. <SES...@ya...> - 2006-05-08 17:53:57
|
I have no idea if this is practical, but would it make sense to = introduce a Dialect 4 (or 4 and 5, if we need something like Dialect 2 to detect incompatibilities?) This could be used to disable = the use of internal functions too, so if you left your DB on dialect 3, nothing would change, but if you migrated to 4, your UDFs = might be blocked by internal functions of the same name. -----Original Message----- From: fir...@li... = [mailto:fir...@li...] On Behalf Of Dmitry = Yemanov Sent: Sunday, May 07, 2006 03:51 AM To: fir...@li... Subject: [Firebird-devel] Changed UPDATE behaviour All, I'm about to commit the SQL compliant behaviour of the UPDATE statement. = The=20 difference is that assignments of the SET clause are processed using=20 differrent contexts now. For example, in "SET A =3D B" value A is = resolved=20 using the target context while value B is resolved using the source = context.=20 In particular, it means that "SET A =3D B, B =3D A" will exchange column = values=20 instead of making them both equal to B (as now). My only question is whether we should keep possibility to restore the = legacy=20 behaviour via a config option or not. I know that some people = intentionally=20 use the legacy semantics. If so, does OldUpdateSemantics sounds good or=20 someone could suggest a better naming? Of course, the stored BLR will = keep=20 the old semantics, so people will need to recompile their PSQL objects = in=20 order to make their logic SQL compliant. Dmitry ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server = v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 Firebird-Devel mailing list, web interface at = https://lists.sourceforge.net/lists/listinfo/firebird-devel |