Re: Turkish downcasting in PL/pgSQL - Mailing list pgsql-bugs

From ntufar
Subject Re: Turkish downcasting in PL/pgSQL
Date
Msg-id 1092340074.2945.24.camel@localhost
Whole thread Raw
In response to Re: Turkish downcasting in PL/pgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
12-08-2004 Perþembe günü saat 22:27 sularýnda, Tom Lane dedi ki:
> ntufar <ntufar@pisem.net> 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 put a global deffinition
> > you are talking below.
>
> Um, the attachment was unreadable :-( but I get the idea.

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'$@' $<

>
> 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.

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

>
>             regards, tom lane

Regards,
Nicolai Tufar

pgsql-bugs by date:

Previous
From: "PostgreSQL Bugs List"
Date:
Subject: BUG #1216: pgcrypto:hmac() segfaults
Next
From: ntufar
Date:
Subject: Re: Turkish downcasting in PL/pgSQL