Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> A few minutes before I tried on a Debian unstable, as Nicolai reported.
> But all the regression tests passed again, using the latest flex +
> glibc... I can't reproduce the problem :( Or there is not a bug :)
Hmph. Either Nicolai has a weird locale s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 16 Aug 2004, Tom Lane wrote:
> > I'm using the latest tr_TR locale of glibc, and flex-2.5.4a-29 (of RHEL)
> > and flex-2.5.4a-31 (of FC 2).
>
> > What am I missing?
>
> If you built from a tarball, then the flex run is already done for
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> All 96 tests passed.
> I'm using the latest tr_TR locale of glibc, and flex-2.5.4a-29 (of RHEL)
> and flex-2.5.4a-31 (of FC 2).
> What am I missing?
If you built from a tarball, then the flex run is already done for you.
Remove src/pl/plpgsql/src/pl_
Hi,
On Thu, 12 Aug 2004, Tom Lane wrote:
> > flex (flex version 2.5.4) incorporates case-insensitivity in it's
> > state tables because if I run flex stage with LANG=C everything
> > works fine.
>
> Ick. That is of course why it worked for me when I tested it :-(
Nicolai is on holiday now.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have tried running flex (2.5.4) with a number of different locales
> including tr_TR, but the output file is always the same. Can you show
> us a diff of the generated files?
Hmm ... a quick look at the flex sources shows that flex does rely on
t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> You'd have to set LC_ALL=C to be really sure to override everything.
> But I would stay away from doing that globally, because all the
> translation work in gcc and make would go to waste.
Agreed. I was toying with changing the FLEX variable to co
ntufar wrote:
> Apparently problem is caused by the following directive:
>
> %option case-insensitive
>
> on line 76 in file src/pl/plpgsql/src/scan.l
>
> flex (flex version 2.5.4) incorporates case-insensitivity in it's
> state tables because if I run flex stage with LANG=C everything
> works
Tom Lane wrote:
> Peter, any thoughts on this one way or the other? At the moment
> plpgsql's scan.l seems to be the only use of '%option
> case-insensitive' but we have enough flex lexers laying about that I
> wouldn't be surprised to have this same risk elsewhere. Is it
> reasonable to try to f
Greetings,
12-08-2004 Perşembe günü saat 18:32 sularında, Tom Lane dedi ki:
ntufar <[EMAIL PROTECTED]> writes:
> > flex (flex version 2.5.4) incorporates case-insensitivity in it's
> > state tables because if I run flex stage with LANG=C everything
> > works fine.
>
> Ick. That is of course why
12-08-2004 Perşembe günü saat 22:27 sularında, Tom Lane dedi ki:
> ntufar <[EMAIL PROTECTED]> writes:
> > I attached a diff of fix that adds LANG=C; before call to $(FLEX).
> > Fixes the problem here but I don't know if adding environment variable
> > assignment like this is appropriate. I am not t
ntufar <[EMAIL PROTECTED]> writes:
> I attached a diff of fix that adds LANG=C; before call to $(FLEX).
> Fixes the problem here but I don't know if adding environment variable
> assignment like this is appropriate. I am not too fluent in PostgreSQL
> build environment and do not know where one can
ntufar <[EMAIL PROTECTED]> writes:
> flex (flex version 2.5.4) incorporates case-insensitivity in it's
> state tables because if I run flex stage with LANG=C everything
> works fine.
Ick. That is of course why it worked for me when I tested it :-(
> A quick and dirty fix could be implemented b
12 matches
Mail list logo
