Re: Turkish downcasting in PL/pgSQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Turkish downcasting in PL/pgSQL
Дата
Msg-id 29209.1092324761@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Turkish downcasting in PL/pgSQL  (ntufar <ntufar@pisem.net>)
Ответы Re: Turkish downcasting in PL/pgSQL  (ntufar <ntufar@pisem.net>)
Re: Turkish downcasting in PL/pgSQL  (Peter Eisentraut <peter_e@gmx.net>)
Re: Turkish downcasting in PL/pgSQL  (Devrim GUNDUZ <devrim@gunduz.org>)
Список pgsql-bugs
ntufar <ntufar@pisem.net> 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 by placing
>      LANG=C
>      export LANG
> in file src/pl/plpgsql/src/Makefile before calling flex.

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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: Notifications in JDBC driver not correct for V3 protocol
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Turkish downcasting in PL/pgSQL