FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> 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.