a_dur...@hotmail.com writes:
> prod=# SELECT TO_CHAR('2013-03-01'::date,'DAY');
> to_char
> --
> FRÄ°DAY
> (1 row)
> But it must return as FRIDAY.
> Our database lc_collate is tr_TR.UTF-8 and encoding is UTF8.
It looks like the cause of this is that the result is computed as
str_toupper(
On Sun, 2013-02-17 at 15:51 +0100, Christian Hammers wrote:
> The postmaster command does not list "--config-file" in its help
It is included under
--NAME=VALUE set run-time parameter
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
and...@tao11.riddles.org.uk writes:
> The SQL function handler, fmgr_sql, isn't prepared to deal with the
> possibility that the fcache entry may be left over from a previous query
> that failed.
Yeah. The immediate cause of that failure is that it supposes that it's
continuing execution of the S
I wrote:
> Or we could add fields recording the current transaction/subtransaction
> IDs, then throw away and regenerate the function cache entry if that
> subxact is no longer active. This would be a bit more invasive/riskier
> than throwing a "not supported" error, but it would preserve the
> fu
Hi there,
First off, let me tell you that I've tried successfully the "trust" option in
pg_hba.conf
I've also searched as much litterature as possible on my issue but it always
comes down to the pg_hba.conf trick.
It just happens that I cannot connect to the server without the "trust" option
s
On Sun, 2013-03-03 at 10:42 -0500, Tom Lane wrote:
> I think the use of str_toupper() is appropriate when processing the
> locale-specific string for a TMDAY specification; but plain DAY is not
> supposed to be locale-dependent, so we probably should use an
> ASCII-only upcasing rule in the non-TM
