Skip to Content.
Sympa Menu

freetds - Re: [freetds] parsing T-SQL with flex & yacc (was: segfault in Perl'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: segfault in Perl'sEmail::Store when using freetds)
  • Date: Tue, 15 Nov 2005 14:34:02 +0300

James,
I would like to contribute parser into such strong project like FreeTDS if I
only could parse its task properly ;).
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)
The second question stuck me in longterm thought:
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?
Seems their SQLDescribeParam has a real implementation problems and
deviations. As example, Easysoft for Sybase(Oracle driver has the same issue)
http://www.mail-archive.com/dbi-users AT perl.org/msg25754.html and MS
http://support.microsoft.com/default.aspx?scid=kb;en-us;273813
,http://support.microsoft.com/default.aspx?scid=kb;en-us;325243.
And third...
May be T-Sql has grammar not fully LALR and my revelation about yacc is vain,
but it should be investigated in more details. Any opinions would be covered.
Has anybody viable reasons for using non LALR grammar?

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: Monday, November 14, 2005 7:11 PM
> To: FreeTDS Development Group
> Subject: [freetds] parsing T-SQL with flex & yacc (was:
> segfault in Perl'sEmail::Store when using freetds)
>
> > From: VZverev AT genesis.spb.ru
> > Sent: Sunday, November 13, 2005 5:16 PM
> >
> > Hello James, I could try to do parser generator such as
> 'bind param[i]
> > is attribute of object..' with yacc style grammar in flex notation.
> > What do you think about 'embedded SQL parser' (scn2.l) from
> > http://examples.oreilly.com/lex/progs.zip, is it fair enough for
> > starting point?
>
> Vitaly,
>
> That would be a great contribution. Every time I read about
> yacc my eyes roll back in their sockets.
>
> Not that I didn't try. I found
> ftp://ftp.ora.com/published/oreilly/nutshell/lexyacc/ , which
> is from the O'Reilly nutshell book "lex & yacc" by Tony
> Mason, John Levine, and Doug Brown
> (http://www.oreilly.com/catalog/lex/index.html). Take your pick.
>
> Both files are probably copyrighted, even though the source
> doesn't say so. Perhaps we could get permission, but we can
> work that out later.
> At least it's a starting point.
>
> Let me know what you decide.
>
> Regards,
>
> --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