Message-Id: <m11c4RM-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] bison
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Fri, 15 Oct 1999 12:18:24 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us, peter_e@gmx.net, pgsql-docs@postgreSQL.org,
	pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <3806AE9C.929B5F2A@alumni.caltech.edu> from "Thomas Lockhart" at
	Oct 15, 99 04:33:32 am
Content-Type: text

>
> > >> You might want to include into the installation instructions (or whereever
> > >> it will end up) that GNU bison 1.25 is required. (right after the flex
> > >> stuff)
> > > We haven't been careful about building and shipping the bison output
> > > in the tarball distribution, as we have for the main parser.
> > Huh?  src/tools/release_prep automatically builds both the main parser
> > and ecpg bison output files.  Is there other stuff it should be
> > handling too?
>
> afaik some of Jan's language stuff uses yacc also...

    Yepp   -   PL/pgSQL   has   it's   own  scanner/parser  (i.e.
    flex/bison). The  tricky  part  in  this  case  is  that  the
    languages  object  file  will  be  loaded at runtime into the
    backend, where the main scanner/parser  is  already  present.
    Thus  I'm  mangling with sed(1) over the generated sources to
    avoid global symbol conflicts.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #