Skip to Content.
Sympa Menu

freetds - Re: [freetds] parsing T-SQL with flex & yacc (was: segfaultinPerl'sEmail::Store when using freetds)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Зверев Виталий Борисович <VZverev AT genesis.spb.ru>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] parsing T-SQL with flex & yacc (was: segfaultinPerl'sEmail::Store when using freetds)
  • Date: Wed, 16 Nov 2005 01:15:28 +0300

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
>




Archive powered by MHonArc 2.6.24.

Top of Page