Your name :
Your email address :


System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium

Operating System (example: Linux 2.4.18) : Debian unstable
Linux 2.6.6-1-k7

PostgreSQL version (example: PostgreSQL-8.0): PostgreSQL-8.0 CVS HEAD

Compiler used (example: gcc 2.95.2) : gcc 3.3.4


Please enter a FULL description of your problem:
------------------------------------------------

Problems with Turkish locale are widely known to developers.
Another one, now in PL/pgSQL have reared it's ugly head.
Regression tests are failing at triggers, plpgsql, copy2
and rangefuncs. Examienation of regression.diff showed that
the failures were due to unrecognised statements like
BEGIN, RAISE and IF in PL/pgSQL functions. Replacing
capital "I" with lower-case "i" (BEGiN, RAiSE, iF) completely
sloves the problem.


If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

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 fine. A quick and dirty fix could be implemented by placing

LANG=C
export LANG

in file src/pl/plpgsql/src/Makefile before calling flex.

A long term fix can be done by implementing a function
for keyword lookup like ScanKeywordLookup() in
src/backend/parser/keywords.c.

I would gladly prepare a patch and send it for your consideration
tomorrow morning.

Best regards,
Nicolai Tufar


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

ntufar <ntufar (AT) pisem (DOT) net> writes:
Ick. That is of course why it worked for me when I tested it :-(

This is probably what we'd better do. Otherwise we have
build-context-dependency in the system's behavior, which is bad.

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 force
LANG=C in some global fashion during the build?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

ntufar <ntufar (AT) pisem (DOT) net> writes:
Um, the attachment was unreadable :-( but I get the idea.

As for the global solution, I was wondering if it would work to put
"LANG=C" right inside the definition of $(FLEX). That would ensure
the right behavior from all our flex builds without unnecessarily
messing up people's build environments otherwise. I don't know however
whether this would parse properly.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

12-08-2004 Perþembe günü saat 22:27 sularýnda, Tom Lane dedi ki:
Something to do with my mail provider, sorry.
in file src/pl/plpgsql/src/Makefile:
LANG=C;$(FLEX) $(FLEXFLAGS) -Pplpgsql_base_yy -o'$@' $<
instead of
$(FLEX) $(FLEXFLAGS) -Pplpgsql_base_yy -o'$@' $<

The only thing that comest in mind is that it may break Win32 port.
Can someone comment on this?

Regards,
Nicolai Tufar


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--=-XoaTFdqoFlGxkKzIit1j
Content-Type: text/plain; charset=ISO-8859-9
Content-Transfer-Encoding: 8bit

Greetings,


12-08-2004 Perþembe günü saat 18:32 sularýnda, Tom Lane dedi ki:
ntufar <ntufar (AT) pisem (DOT) net> writes:
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 put a global deffinition
you are talking below.

Peter, any thoughts on this one way or the other? At the moment
Nicolai Tufar


--=-XoaTFdqoFlGxkKzIit1j
Content-Disposition: attachment; filename=TurkishFlex.diff
Content-Type: text/x-patch; name=TurkishFlex.diff; charset=ISO-8859-9
Content-Transfer-Encoding: base64

Indexsrc/pl/plpgsql/src/MakefileAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARCSfile/projects/cvsr
oot/pgsqlserver/src/pl/plpgsql/src/Makefilevretrieving0K3r4r
IqJ9dunYn33K9dujGpHn4pXrK3P6Zf6ZaYLKpf7K3PzGpHn4pX tybp9tNONf
dtd9dNNNNdurK3P6Zf6ZaYLKpf7K3PzGpHn4pXtdgLoNtNONfO OON9NNNO+/
N7K3HYq/6ZbHGp3LHGp5Yn3XnxSxFxSxFxSxFxSwBkj6ZaYLKpW2rHssqH pb
HporLIp4H5XsXp3Yn++/N7K3HYq/6ZbHGp3LHGp5Yn3XnxSxFywDRgAhSxFx
SxFxSwBkj6ZaYLKpW2rHssqHpbHporLIp4H5XsXp3Q==

--=-XoaTFdqoFlGxkKzIit1j
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

--=-XoaTFdqoFlGxkKzIit1j--

Tom Lane wrote:
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.

I would also suggest that Nicolai report this issue to the flex
developers. It's only bound to reappear everywhere case-insensitive
flex scanners are used.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

ntufar wrote:
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?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
Agreed. I was toying with changing the FLEX variable to contain
"LC_ALL=C flex" but I'm a bit worried about breaking the build on
some platforms (especially Windows).

True. Maybe we should just call it a flex bug and wait for them to
fix it. It's not going to affect builds from tarballs anyway, only
people who build from CVS.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
Hmm ... a quick look at the flex sources shows that flex does rely on
the <ctype.h> routines for case-folding, so I have no doubt that
ntufar's report is accurate. Maybe you used the wrong tr_TR locale?

(Just for the record, though, I can't see any change in the generated
pl_scan.c output in any of the tr_TR variants available on either HPUX
or OS X. I don't have a full set of locales installed on my Linux
machine so I can't try it there.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Hi,

On Thu, 12 Aug 2004, Tom Lane wrote:

Nicolai is on holiday now. I tested on my Fedora Core 2 and RHEL 3 ES
systems and all regression tests passed:

======================
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?

Regards,
--
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend