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!

Fri, 18 Oct 2002 17:34:17 +0200
Michael Meskes <meskes@postgresql.org>
ECPG and bison

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, Pennsylvania 19073

Fri, 18 Oct 2002 11:48:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG and bison
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!

Fri, 18 Oct 2002 18:56:56 +0200
Michael Meskes <meskes@postgresql.org>
Re: ECPG and bison
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

Fri, 18 Oct 2002 14:51:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG and bison 
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


18 Oct 2002 15:03:52 -0500
Larry Rosenman <ler@lerctr.org>
Re: ECPG and bison
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.
Fri, 18 Oct 2002 16:16:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG and bison
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

Fri, 18 Oct 2002 16:49:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG and bison 
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, Pennsylvania 19073

Fri, 18 Oct 2002 18:08:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG and bison
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


Sat, 19 Oct 2002 00:09:49 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: ECPG and bison

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
>


Sat, 19 Oct 2002 00:01:49 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: ECPG and bison
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 :(



Sat, 19 Oct 2002 00:03:30 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: ECPG and bison 
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


18 Oct 2002 22:06:40 -0500
Larry Rosenman <ler@lerctr.org>
Re: ECPG and bison
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!

Mon, 21 Oct 2002 14:56:26 +0200
Michael Meskes <meskes@postgresql.org>
Re: ECPG and bison
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, Pennsylvania 19073

Mon, 21 Oct 2002 10:42:20 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG and bison