Thread: ECPG and bison

ECPG and bison

From
Michael Meskes
Date:
Could anyone please tell me if we found a solution? It seems I missed
any discussion or whatsoever. The only things I know is that
postgresql.org still has bison 1.35 installed and 7.3 release is
nearing.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!


Re: ECPG and bison

From
Bruce Momjian
Date:
Yes, we are going to upgrade to bison 1.50 on our main server as soon as
Marc gets it installed.  If you want to make your changes and commit
those now, you can, because I assume your bison 1.50 output will get
into CVS.  I have bison 1.50 here too.

---------------------------------------------------------------------------

Michael Meskes wrote:
> Could anyone please tell me if we found a solution? It seems I missed
> any discussion or whatsoever. The only things I know is that
> postgresql.org still has bison 1.35 installed and 7.3 release is
> nearing.
> 
> Michael
> -- 
> Michael Meskes
> Michael@Fam-Meskes.De
> Go SF 49ers! Go Rhein Fire!
> Use Debian GNU/Linux! Use PostgreSQL!
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: ECPG and bison

From
Michael Meskes
Date:
On Fri, Oct 18, 2002 at 11:48:33AM -0400, Bruce Momjian wrote:
> Yes, we are going to upgrade to bison 1.50 on our main server as soon as
> Marc gets it installed.  If you want to make your changes and commit

Okay.

> those now, you can, because I assume your bison 1.50 output will get
> into CVS.  I have bison 1.50 here too.

The changes are there already, I just have to fold the ecpg.big branch
into HEAD.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!


Re: ECPG and bison

From
Tom Lane
Date:
Michael Meskes <meskes@postgresql.org> writes:
>> those now, you can, because I assume your bison 1.50 output will get
>> into CVS.  I have bison 1.50 here too.

> The changes are there already, I just have to fold the ecpg.big branch
> into HEAD.

Probably you should refrain from doing that until Marc installs 1.50
at postgresql.org, else the nightly snapshots will be broken, to no
one's advantage.

Marc, can you do something about installing bison 1.50 soon?

(Guess I'd better get it loaded on my own machines, too...)
        regards, tom lane


Re: ECPG and bison

From
Larry Rosenman
Date:
On Fri, 2002-10-18 at 13:51, Tom Lane wrote:
> Michael Meskes <meskes@postgresql.org> writes:
> >> those now, you can, because I assume your bison 1.50 output will get
> >> into CVS.  I have bison 1.50 here too.
> 
> > The changes are there already, I just have to fold the ecpg.big branch
> > into HEAD.
> 
> Probably you should refrain from doing that until Marc installs 1.50
> at postgresql.org, else the nightly snapshots will be broken, to no
> one's advantage.
> 
> Marc, can you do something about installing bison 1.50 soon?
> 
> (Guess I'd better get it loaded on my own machines, too...)
Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
by). 

LER
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: ECPG and bison

From
Bruce Momjian
Date:
Larry Rosenman wrote:
> On Fri, 2002-10-18 at 13:51, Tom Lane wrote:
> > Michael Meskes <meskes@postgresql.org> writes:
> > >> those now, you can, because I assume your bison 1.50 output will get
> > >> into CVS.  I have bison 1.50 here too.
> >
> > > The changes are there already, I just have to fold the ecpg.big branch
> > > into HEAD.
> >
> > Probably you should refrain from doing that until Marc installs 1.50
> > at postgresql.org, else the nightly snapshots will be broken, to no
> > one's advantage.
> >
> > Marc, can you do something about installing bison 1.50 soon?
> >
> > (Guess I'd better get it loaded on my own machines, too...)
> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> by).

I can confirm that:

    http://ftp.gnu.org/gnu/bison/

Attached is the Changelog since 1.50.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
2002-10-14  Akim Demaille  <akim@epita.fr>

    Version 1.75.

2002-10-14  Akim Demaille  <akim@epita.fr>

    * tests/Makefile.am (maintainer-check-posix): New.

2002-10-14  Akim Demaille  <akim@epita.fr>

    * data/glr.c [YYDEBUG] (YYLEFTMOST_STATE): Initialize the yyloc
    member.

2002-10-14  Akim Demaille  <akim@epita.fr>

    * src/tables.c (table_ninf_remap): base -> tab.
    Reported by Matt Rosing.

2002-10-14  Paul Eggert  <eggert@twinsun.com>

    * tests/action.at, tests/calc.at, tests/conflicts.at,
    tests/cxx-type.at, tests/headers.at, tests/input.at,
    tests/regression.at, tests/synclines.at, tests/torture.at:
    Say "bison -o foo.c foo.y", not "bison foo.y -o foo.c",
    so that the tests still work even if POSIXLY_CORRECT is set.
    * doc/bison.texinfo (Rpcalc Compile, Invocation): Likewise.

    * data/c.m4 (b4_int_type): Use yysigned_char instead of signed char,
    for portability to K&R hosts.  Fix typo: signed char is guaranteed
    only to 127, not to 128.
    * data/glr.c (yysigned_char): New type.
    * data/yacc.c (yysigned_char): Likewise.
    * tests/regression.at (Web2c Actions): signed char -> yysigned_char.

2002-10-13  Paul Eggert  <eggert@twinsun.com>

    * data/yacc.c (yyparse): Rewrite to avoid "comparison is always
    true due to limited range of data type" warning from GCC.

    * data/c.m4 (b4_token_defines): Protect against double-inclusion
    by wrapping enum yytokentype's definition inside #ifndef
    YYTOKENTYPE.  This undoes a bug I introduced on 2002-10-12.

2002-10-13  Akim Demaille  <akim@epita.fr>

    * data/glr.c (yyglrShiftDefer, yyaddDeferredAction, yydoAction):
    Un yy- yyrhs to avoid the name clash with the global YYRHS.

2002-10-13  Akim Demaille  <akim@epita.fr>

    * Makefile.maint: Update from Autoconf 2.54.
    * m4/strerror_r.m4 (AC_FUNC_STRERROR_R): Remove, shipped with 2.54.

2002-10-13  Akim Demaille  <akim@epita.fr>

    * src/print.c (print_state): Separate the list of solved conflicts
    from the other items.
    * tests/conflicts.at (Resolved SR Conflicts): Adjust.

2002-10-13  Akim Demaille  <akim@epita.fr>

    Let nondeterministic skeletons be usable with deterministic
    tables.

    With the patch, GAWK compiled by GCC without -O2 passes its test
    suite using a GLR parser driven by LALR tables.  It fails with -O2
    because `struct stat' gives two different answers on my machine:
    88 (definition of an auto var) and later 96 (memset on this var).
    Hence the stack is badly corrumpted.  The headers inclusion is to
    blame: if I move the awk.h inclusion before GLR's system header
    inclusion, the two struct stat have the same size.

    * src/tables.c (pack_table): Always create conflict_table.
    (token_actions): Always create conflict_list.
    * data/glr.c (YYFLAG): Remove, unused.

2002-10-13  Akim Demaille  <akim@epita.fr>

    * configure.ac (AC_GNU_SOURCE): Use it instead of hand written code.
    (O0FLAGS): New.
    (VALGRIND, GXX): New.
    * tests/atlocal.in (CFLAGS): Use O0FLAGS.
    * tests/bison.in: Run $PREBISON a pre-command.
    * tests/Makefile.am (maintainer-check, maintainer-check-valgrind)
    (maintainer-check-g++): New.
    * Makefile.am (maintainer-check): New.

2002-10-13  Akim Demaille  <akim@epita.fr>

    * data/glr.c: Formatting changes.
    Tweak some trace messages to match yacc.c's.

2002-10-13  Akim Demaille  <akim@epita.fr>

    GLR parsers sometimes raise parse errors instead of performing the
    default reduction.
    Reported by Charles-Henry de Boysson.

    * tests/calc.at (_AT_CHECK_CALC, _AT_CHECK_CALC_ERROR): Don't
    check the length of the    traces when %glr.
    (_AT_CHECK_CALC_ERROR): Also skip `^Stack' lines, coming from
    GLR's traces.
    (AT_CHECK_CALC_LALR, AT_CHECK_CALC_GLR): New.
    Test GLR parsers.
    * data/glr.c (YYLEFTMOST_STATE): Fix its value.
    (yyltype): Remove the yy prefix from the member names.
    (yytable): Complete its comment.
    (yygetLRActions): Map error action number from YYTABLE from
    YYTABLE_NINF to 0.
    (yyisErrorAction): No longer compare YYACTION to YYPACT_NINF
    (which was a bug: it should have been YYTABEL_NINF, and yet it was
    not satisfying as we could compare an YYACTION computed from
    YYDEFACT to YYTABLE_NINF although they are unrelated): 0 is the
    only value for error actions.
    (yyreportParseError): In verbose parse error messages, don't issue
    `error' in the list of expected tokens.
    * data/yacc.c (yyparse) <yybackup>: Rewrite the decoding of the
    next action to perform to match glr.c's decoding.
    (yytable): Complete its comment.

2002-10-13  Paul Eggert  <eggert@twinsun.com>

    Fix problem reported by Henrik Grubbstroem in
    <http://mail.gnu.org/pipermail/bug-bison/2002-October/001670.html>:
    "nonterm: { $$ = 123; } { $$ = $1; };" was wrongly rejected,
    because the Bison parser reads the second action before reducing
    the first one.
    * src/scan-gram.l (rule_length): New static var.
    Use it to keep track of the rule length in the scanner, since
    we can't expect the parser to be in lock-step sync with the scanner.
    (handle_action_dollar, handle_action_at): Use this var.
    * tests/actions.at (Exotic Dollars): Test for the problem.

2002-10-12  Paul Eggert  <eggert@twinsun.com>

    * lib/timevar.c [! IN_GCC && HAVE_SYS_TIME_H]: Include <sys/time.h>.
    * m4/timevar.m4 (BISON_PREREQ_TIMEVAR): Check for <sys/time.h>.
    Include <sys/time.h> when checking for clock_t and struct tms.
    Use same include order as source.
    This is for the SunOS 4.1.4 porting bug reported by Peter Klein in
    <http://mail.gnu.org/pipermail/bug-bison/2002-October/001674.html>.

    * lib/timevar.c: Update copyright date and clarify comments.
    (get_time) [IN_GCC]: Keep the GCC version for reference.

    * lib/timevar.c, lib/timevar.h, lib/timevar.def: Import
    GCC version as of today, then merge Bison's changes.
    Change "GCC" to "Bison" in copyright notice.  timevar.def's
    author is Akim, so change that too.

    * src/reader.c (grammar_current_rule_check):
    Don't worry about the default action if $$ is untyped.
    Prevents bogus warnings reported by Jim Gifford in
    <http://mail.gnu.org/pipermail/bug-bison/2002-October/001673.html>.

    * data/c.m4 (b4_token_enum): Do not define YYTOKENTYPE.
    * data/glr.c, data/lalr1.cc, data/yacc.c:
    Output token definitions before the first part of user declarations.
    Fixes compatibility problem reported by Jim Gifford for kbd in
    <http://mail.gnu.org/pipermail/bug-bison/2002-October/001672.html>.

2002-10-11  Paul Eggert  <eggert@twinsun.com>

    * data/yacc.c (yyreport_parse_error): Remove, putting its body into...
    (yyparse): here.  This undoes some of the 2002-07-25 change.
    Compatibility problem reported by Ralf S. Engelschall with
    OSSP cfg <http://www.ossp.org/pkg/lib/cfg/>.

2002-10-11  Akim Demaille  <akim@epita.fr>

    * tests/regression.at Characters Escapes): New.
    * src/scan-gram.l (SC_ESCAPED_CHARACTER): Accept \' in strings and
    characters.
    Reported by Jan Nieuwenhuizen.

2002-10-11  Akim Demaille  <akim@epita.fr>

    * po/id.po: New.

2002-10-10  Paul Eggert  <eggert@twinsun.com>

    Portability fixes for bitsets; this also avoids several GCC
    warnings.

    * lib/abitset.c: Include <stddef.h>, for offsetof.
    * lib/lbitset.c: Likewise.

    * lib/abitset.c (abitset_bytes): Return a size that is aligned
    properly for vectors of objects.  Do not assume that adding a
    header size to a multiple of a word size yields a value that is
    properly aligned for the whole union.
    * lib/bitsetv.c (bitsetv_alloc): Likewise.

    * lib/bitset_stats.c (bitset_stats_bytes): Adjust to new,
    unique names for structures.
    * lib/ebitset.c (ebitset_bytes): Likewise.
    * lib/lbitset.c (lbitset_bytes): Likewise.

    * lib/abitset.c (abitset_ones, abitset_zero, abitset_empty_p,
    abitset_copy1, abitset_not, abitset_equal_p, abitset_subset_p,
    abitset_disjoint_p, abitset_and, abitset_and_cmp, abitset_andn,
    abitset_andn_cmp, abitset_or, abitset_or_cmp, abitset_xor,
    abitset_xor_cmp, abitset_and_or, abitset_and_or_cmp,
    abitset_andn_or, abitset_andn_or_cmp, abitset_or_and,
    abitset_or_and_cmp, abitset_copy): Supply prototype decls,
    to improve the type-checking that GCC can do.
    * lib/bitset.c (bitset_op4_cmp): Likewise.
    * lib/bitset_stats.c (bitset_stats_count,
    bitset_stats_empty_p, bitset_stats_ones, bitset_stats_zero,
    bitset_stats_copy, bitset_stats_disjoint_p,
    bitset_stats_equal_p, bitset_stats_not, bitset_stats_subset_p,
    bitset_stats_and, bitset_stats_and_cmp, bitset_stats_andn,
    bitset_stats_andn_cmp, bitset_stats_or, bitset_stats_or_cmp,
    bitset_stats_xor, bitset_stats_xor_cmp, bitset_stats_and_or,
    bitset_stats_and_or_cmp, bitset_stats_andn_or,
    bitset_stats_andn_or_cmp, bitset_stats_or_and,
    bitset_stats_or_and_cmp): Likewise.
    * lib/lbitset.c (lbitset_and, lbitset_and_cmp, lbitset_andn,
    lbitset_andn_cmp, lbitset_or, lbitset_or_cmp, lbitset_xor,
    lbitset_xor_cmp, lbitset_empty_p, lbitset_ones, lbitset_not,
    lbitset_subset_p, lbitset_disjoint_p, debug_lbitset): Likewise.

    * lib/abitset.h: Include bitset.h, not bbitset.h.
    * lib/ebitset.h: Likewise.
    * lib/lbitset.h: Likewise.

    * lib/bbitset.h: (enum_bitset_ops, enum_bitset_type): New types.
    All instances of parameters of type enum bitset_opts are now of
    type enum_bitset_opts, to conform to the C Standard, and similarly
    for enum_bitset_type.
    * lib/ebitset.c (enum_ebitset_find_mode): Likewise.
    * lib/lbitset.c (enum_lbitset_find_mode): Likewise.

    Do not use "struct bitset_struct" to mean different things in
    different modules.  Not only is this confusing, it violates
    the C Standard, which requires that structure types in different
    modules must be compatible if one is to be passed to the other.
    * lib/bbitset.h (bitset): Now points to a union, not to a struct.
    All instances of "struct bitset_struct *" replaced with "bitset".
    * lib/bitset.h (struct bitset_struct): Remove, replacing with....
    (union bitset_union, struct abitset_struct, struct ebitset_struct,
    struct lbitset_struct, struct bitset_stats_struct): New types.
    All uses of struct bitset_struct changed to union bitset_union,
    etc.
    * lib/abitset.c    (struct abitset_struct, abitset,
    struct bitset_struct): Remove.
    * lib/bitset_stats.c (struct bitset_stats_struct, bitset_stats,
    struct bitset_struct): Remove.
    * lib/ebitset.c (struct ebitset_struct, ebitset, struct
    bitset_struct): Remove.
    * lib/lbitset.c (struct lbitset_struct, lbitset, bitset_struct):
    Likewise.

    Do not call a function of type T using a call that assumes the
    function is of a different type U.  Standard C requires that a
    function must be called with a type that is compatible with its
    definition.
    * lib/bbitset.h (bitset_and_or_, bitset_andn_or_, bitset_or_and_):
    New decls.
    * lib/bitset.c (bitset_and_or_, bitset_andn_or_, bitset_or_and_):
    New functions.
    * lib/ebitset.c (PFV): Remove.
    * lib/lbitset.c (PFV): Likewise.
    * lib/ebitset.c (ebitset_and, ebitset_andn, ebitset_or,
    ebitset_xor, ebitset_copy, ebitset_ones, ebitset_empty_p): New
    decls.
    (ebitset_and, ebitset_andn, ebitset_or, ebitset_xor): New functions.
    (ebitset_vtable): Use them.
    * lib/lbitset.c (lbitset_and, lbitset_andn, lbitset_or,
    lbitset_xor): New functions.
    (lbitset_vtable): Use them.

    * lib/bitset.h (bitset_next, bitset_prev, bitset_only_set_p):
    Declare.

    * lib/bitsetv.c (bitsetv_alloc): Add a cast to (void *) to avoid a
    GCC warning.
    * lib/lbitset.c (LBITSET_CURRENT1): Likewise.
    Use offsetof, for simplicity.

2002-10-06  Paul Eggert  <eggert@twinsun.com>

    * lib/bitset.h (bitset_reset): Do not assume that bitset_word is
    the same width as int.  This reapplies a hunk of the 2002-08-12 patch
    <http://mail.gnu.org/pipermail/bison-patches/2002-August/001111.html>,
    which was inadvertently undone by the 2002-09-30 patch.
    * lib/lbitset.c (debug_lbitset): Do not assume that bitset_word is
    the same width as int.


Re: ECPG and bison

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Larry Rosenman wrote:
>> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
>> by). 

> I can confirm that:
>     http://ftp.gnu.org/gnu/bison/
> Attached is the Changelog since 1.50.

Urgh.  Nothing like major releases 2 weeks apart to give one a nice warm
comfy feeling about the stability of one's tools.

Offhand it looks like these are nearly all bug fixes, and so we'd better
standardize on 1.75 not 1.50.  But I wonder what will be out next
week...
        regards, tom lane


Re: ECPG and bison

From
Peter Eisentraut
Date:
Michael Meskes writes:

> Could anyone please tell me if we found a solution? It seems I missed
> any discussion or whatsoever. The only things I know is that
> postgresql.org still has bison 1.35 installed and 7.3 release is
> nearing.

I suggest that you merge your branch as soon as you are ready and force
the issue a bit.  It's not like the bison installation on
postgresql.org can make the world stop.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: ECPG and bison

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Michael Meskes writes:
> 
> > Could anyone please tell me if we found a solution? It seems I missed
> > any discussion or whatsoever. The only things I know is that
> > postgresql.org still has bison 1.35 installed and 7.3 release is
> > nearing.
> 
> I suggest that you merge your branch as soon as you are ready and force
> the issue a bit.  It's not like the bison installation on
> postgresql.org can make the world stop.

Agreed.  We need to push this.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: ECPG and bison

From
"Marc G. Fournier"
Date:
going to be dealing with this this weekend ... Bruce already asked me as
well, just been busy during the week, so had to defer to the weekend ...
if its not in place by tomorrow around, so, 8pm GMT,please feel free to
email-nag me :)


On Fri, 18 Oct 2002, Michael Meskes wrote:

> Could anyone please tell me if we found a solution? It seems I missed
> any discussion or whatsoever. The only things I know is that
> postgresql.org still has bison 1.35 installed and 7.3 release is
> nearing.
>
> Michael
> --
> Michael Meskes
> Michael@Fam-Meskes.De
> Go SF 49ers! Go Rhein Fire!
> Use Debian GNU/Linux! Use PostgreSQL!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>



Re: ECPG and bison

From
"Marc G. Fournier"
Date:
On Fri, 18 Oct 2002, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Larry Rosenman wrote:
> >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> >> by).
>
> > I can confirm that:
> >     http://ftp.gnu.org/gnu/bison/
> > Attached is the Changelog since 1.50.
>
> Urgh.  Nothing like major releases 2 weeks apart to give one a nice warm
> comfy feeling about the stability of one's tools.
>
> Offhand it looks like these are nearly all bug fixes, and so we'd better
> standardize on 1.75 not 1.50.  But I wonder what will be out next
> week...

that's one of hte reasons I've been holding off (the other being a busy
week) ... I *try* to keep stuff like this to what the FreeBSD ports
collection considers a stable release, and it hasn't been updated yet :(




Re: ECPG and bison

From
Larry Rosenman
Date:
On Fri, 2002-10-18 at 22:03, Marc G. Fournier wrote:
> On Fri, 18 Oct 2002, Tom Lane wrote:
> 
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Larry Rosenman wrote:
> > >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> > >> by).
> >
> > > I can confirm that:
> > >     http://ftp.gnu.org/gnu/bison/
> > > Attached is the Changelog since 1.50.
> >
> > Urgh.  Nothing like major releases 2 weeks apart to give one a nice warm
> > comfy feeling about the stability of one's tools.
> >
> > Offhand it looks like these are nearly all bug fixes, and so we'd better
> > standardize on 1.75 not 1.50.  But I wonder what will be out next
> > week...
> 
> that's one of hte reasons I've been holding off (the other being a busy
> week) ... I *try* to keep stuff like this to what the FreeBSD ports
> collection considers a stable release, and it hasn't been updated yet :(
The PR I referred to above is the PR to update to 1.75. 


> 
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: ECPG and bison

From
Michael Meskes
Date:
On Fri, Oct 18, 2002 at 04:16:29PM -0400, Bruce Momjian wrote:
> > Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> > by). 
> 
> I can confirm that:

I just tried Marc's installation of 1.75 and compared the result with my
1.50 compiled version of ecpg grammar and found both .c files to be
identical. Seems the changes didn't effect the parser output.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!


Re: ECPG and bison

From
Bruce Momjian
Date:
Michael Meskes wrote:
> On Fri, Oct 18, 2002 at 04:16:29PM -0400, Bruce Momjian wrote:
> > > Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> > > by). 
> > 
> > I can confirm that:
> 
> I just tried Marc's installation of 1.75 and compared the result with my
> 1.50 compiled version of ecpg grammar and found both .c files to be
> identical. Seems the changes didn't effect the parser output.

Oh, that's very good news.  Makes me feel a little more secure.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073