FreeTDS Development Group

[Зверев Виталий Борисович <VZverev AT genesis.spb.ru>]

James, Frediano,
thanks for comments in friendly atmosphere (I'm not a native English writer, 
so excuse me my ugly essay)
Definitely I was wrong with boring about buildin T-SQL functions (just 
thinking about ones in PL/SQL where overloaded by parameters is normal and 
was carried away). Thanks for offers in mail hosting and project care, I 
think it will be claiming slightly later. Now my driving goal is restoration 
of grammar development framework for rapid modeling of T-SQL draft syntax as 
well to refresh my college lectures in theory of finite-machines for such 
long-run objective.
I have to take a two-weeks time break for self-education and enforce 
difficulty evaluation.

+++
BTW, FireBird like a Sybase has open interface to parametrised Dinamic SQL 
parser & ODBC driver (with SQLDescribeParam implementation) 
http://cvs.sourceforge.net/viewcvs.py/*checkout*/firebird/firebird2/src/dsql/parse.y?rev=1.193.
 

Sincerely yours. 
-------------------------------------------------------
Vitaly Zverev, OCP DBA 8&8i
Oracle E-Business Suite &
Infiniband Linux Cluster Administrator
Genesis Ltd., St.Petersburg, Russia

 

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org 
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of 
> Lowden, James K
> Sent: Tuesday, November 15, 2005 7:18 PM
> To: FreeTDS Development Group
> Subject: Re: [freetds] parsing T-SQL with flex & yacc (was: 
> segfaultinPerl'sEmail::Store when using freetds)
> 
> > From: VZverev AT genesis.spb.ru
> > Sent: Tuesday, November 15, 2005 6:34 AM
> > 
> > I would like to contribute parser into such strong project like 
> > FreeTDS if I only could parse its task properly ;).
> 
> You will be famous.  At least in some circles.  ;-)
> 
> > Okay, at first glance I should organize T-SQL placeholders 
> knowledge 
> > and figure out their transformations and invariants.
> > 
> > 1) DataType(Size,Scale,Nullable) transition for all 
> predicates  ?= , ? 
> > In () , ? <> any and so on
> > 
> > 2) -//- mutations and constraints in buildin functions ( ... where
> > sin(?) = ? And DATEADD ( ? , ?, ? ) = ? )
> > 
> > 3) indirect type conversations (... where ?+'1'+'2' = ?), 
> inline view 
> > attributes and stored proc parameters (by name and by position)
> 
> I think the anwer is "Look Left":
> 
> 1> select 1 + '2' + 3, 1 + '2' + '3', '1' + '2' + '3', '1' + 
> '2' + 3, 1
> + 2 + '3'
> 2> reset
> 1> select 1 + '2' + 3, 1 + '2' + '3', '1' + '2' + '3', '1' + '2' + 3,
> '1' + 2 + '3'
> 2> go
> 
>  ----------- ----------- --- ----------- -----------
>            6           6 123          15           6
> 
> The placeholder's type should matche the type of the 
> operator's other operand.  Of course, you'll get in trouble with 
> 
>       WHERE 1 + '2' = ?
> 
> unless you respect operator precedence, resolving "1 + '2'" 
> before determining the placeholder's type.  
> 
> I don't see any particular difficulty with built-in 
> functions.  Why is "DATEADD ( ? , ?, ? )" a challenge?  
> 
> > What is *STANDARD* in prediction of placeholder metadata
> transformation?
> > Really, if we are planning to mimic SQLDescribeParam, then 
> mimic like 
> > which - Sybase, Ms, EasySoft, etc?
> 
> It's quite messy, isn't it?  Very simply, no one publishes a 
> formal grammar for T-SQL; it's proprietary.  (Easysoft, btw, 
> does publish its lex grammar.)  Rather than try to mimic any 
> one implementation, you might want to try to adhere to the 
> SQL-92 standard:
> 
>       http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
> or    http://www.schemamania.org/projects/freetds/doc/sql1992.txt
> 
> 
> I think it would be good merely to begin with a solid 
> framework.  We don't have to find every corner case on Day 1.  
> 
> If we could support, say, the specific needs of Email::Store, 
> that would be a step forward.  We can ignore user-defined 
> functions and even subqueries for now.  It would be a big 
> step forward to be able to handle simple ON and WHERE 
> clauses, and parameters to functions and stored procedures.  
> 
> +++
> 
> I just want to say that once again Sybase made the right 
> choice.  The server not only has a parser, it has the 
> *definitive* parser.  Asking the server for the datatype of 
> the missing elements in a query is sure to get the right 
> answer, and means one client can deal with many servers.  To 
> require the client to imperfectly duplicate its best guess at 
> the server's parser is to ensure incompatibility and brokeness.  
> 
> If I understand this, we know for sure Microsoft does.  And 
> we also know Microsoft doesn't publish a parser spec, much 
> less a free library, leaving Microsoft alone best situated to 
> provide the ODBC driver for its server.  Sybase, Sun (Java), 
> FreeTDS have to reproduce their technology to compete.  It 
> makes sense ... if you're selling clients.  Of course, 
> Microsoft doesn't sell ODBC drivers; it sells Windows.  
> That's the franchise it's protecting.  
> 
> --jkl
> 
> -----------------------------------------
> The information contained in this transmission may be 
> privileged and confidential and is intended only for the use 
> of the person(s) named above. If you are not the intended 
> recipient, or an employee or agent responsible for delivering 
> this message to the intended recipient, any review, 
> dissemination, distribution or duplication of this 
> communication is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately by 
> reply e-mail and destroy all copies of the original message. 
> Please note that we do not accept account orders and/or 
> instructions by e-mail, and therefore will not be responsible 
> for carrying out such orders and/or instructions.  If you, as 
> the intended recipient of this message, the purpose of which 
> is to inform and update our clients, prospects and 
> consultants of developments relating to our services and 
> products, would not like to receive further e-mail 
> correspondence from the sender, please "reply" to the sender 
> indicating your wishes.  In the U.S.: 1345 Avenue of the 
> Americas, New York, NY 10105.
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>