On 8/25/17 05:14, Ioseph Kim wrote:
> I resolved this problem.
>
> This problem is that dgettext() function use codeset of database's lc_ctype.
>
> below database's lc_ctype is C, but locale is ko_KR.UTF8.
Thank you for following up. As you have discovered, that combination of
locale settings d
Thanks for reply.
I resolved this problem.
This problem is that dgettext() function use codeset of database's lc_ctype.
below database's lc_ctype is C, but locale is ko_KR.UTF8.
I made a new database with lc_ctype is ko_KR.UTF8.
this problem is resolved.
work logs are here.
(10) post
On 8/22/17 01:19, Ioseph Kim wrote:
> 2017-08-22 14:06:21.697 KST [306] 로그: logical replication apply
> worker for subscription "replica_a" has started
> 2017-08-22 14:06:21.698 KST [306] 오류: 발행 서버에 연결 할 수 없음:
> ??? ??? ? ??: ??? ???
> "localhost" (::1) ??? ?? ???,
> 5432 ???
Hi,
I tried ver. 10 beta3.
I had below messages.
-
$ pg_ctl start
서버를 시작하기 위해 기다리는 중완료
서버 시작됨
2017-08-22 14:06:21.248 KST [32765] 로그: IPv6, 주소: "::1", 포트 5433
번으로 접속을 허용합니다
2017-08-22 14:06:21.248 KST [32765] 로그: IPv4, 주소: "127.0.0.1", 포트
5433 번으로 접속을 허용합니다
2017-08-22 14:06:21.364 KST
Alvaro Herrera writes:
> Tom Lane wrote:
>> We could stabilize this test result by forcing lc_messages = C in
>> the foreign server options. However, that would lose regression
>> coverage of situations where the remote locale is different, which
>> doesn't seem like a terribly good thing.
> I d
Tom Lane wrote:
> We could stabilize this test result by forcing lc_messages = C in
> the foreign server options. However, that would lose regression
> coverage of situations where the remote locale is different, which
> doesn't seem like a terribly good thing.
I don't understand what is the ben
I wrote:
> I had not realized (or forgot) that postgres_fdw allows the remote
> end to run in whatever lc_messages locale is default for the remote
> installation. It's a bit surprising that none of the existing test
> cases expose any remote-side messages directly, but evidently not.
> We could
So 8bf58c0d9 immediately blew up in the buildfarm, with eg this
on jaguarundi:
***
*** 130,136
ALTER SERVER loopback OPTIONS (SET dbname 'no such database');
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should fail
ERROR: could not connect to server "loopback"
! DETA
Stefan Huehner writes:
> first i am not sure how the state of the collation work in current git is
> supposed to be with all the discussion going on here... but wanted to get out
> that bug report:
> create table ad_tab (ad_tab_id varchar(32), name varchar(32));
> create function test_trg() R
Stefan Huehner writes:
> first i am not sure how the state of the collation work in current git is
> supposed to be with all the discussion going on here... but wanted to get out
> that bug report:
I think the current state is "plpgsql is about completely broken for
collation operations" :-(.
Hi,
first i am not sure how the state of the collation work in current git is
supposed to be with all the discussion going on here... but wanted to get out
that bug report:
create table ad_tab (ad_tab_id varchar(32), name varchar(32));
create function test_trg() RETURNS TRIGGER LANGUAGE plpgs
On Thu, Apr 03, 2008 at 06:54:50PM +0100, Gregory Stark wrote:
> The big gotcha is what collation to use when comparing with data in the system
> tables, especially the shared system tables. I think we do need to define a
> database-wide encoding and collation to use for system tables. (Unless we c
Tom Lane wrote:
The other issue that'd have to be resolved is the problem of system log
output. I think we'd wish that log messages are written in a uniform
encoding (CSV output in particular is going to have a hard time
otherwise) but what do you do when you need to report something that
incl
Gregory Stark <[EMAIL PROTECTED]> writes:
> The big gotcha is what collation to use when comparing with data in the system
> tables, especially the shared system tables. I think we do need to define a
> database-wide encoding and collation to use for system tables.
You mean cluster-wide? If we ca
Regarding the ICU patch in the commitfest here's my plan.
IMHO the idea of making ICU a hard dependency which Postgres will have to use
forevermore on all systems is a non-starter. I'm not entirely against having
ICU as a supported collation system which packagers on systems where the
system loc
"Stephen Denne" <[EMAIL PROTECTED]> writes:
> i.e. Do I still have to either initdb --locale=C or explicitly use
> text_pattern_ops?
yes, if you want an index to be used
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
-
Given the improvements in 8.3 listed in the release notes:
- Improve efficiency of LIKE/ILIKE, especially for multi-byte character sets
like UTF-8 (Andrew, Itagaki Takahiro)
Does this still hold:
http://www.postgresql.org/docs/8.3/interactive/locale.html
"The drawback of using locales other than
On Fri, Oct 12, 2007 at 06:03:52AM -0700, Trevor Talbot wrote:
> On 10/12/07, Dave Page <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote
> > > That still leaves us with the problem of how to tell whether a locale
> > > spec is bad on Windows. Judging by your example, Windows checks whether
> > > the
Trevor Talbot wrote:
> The encoding output is the one you specified.
OK.
> Keep in mind,
> underneath Windows is mostly working with Unicode, so all characters
> exist and the locale rules specify their behavior there. The encoding
> is just the byte stream it needs to force them all into afte
On 10/12/07, Dave Page <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote
> > That still leaves us with the problem of how to tell whether a locale
> > spec is bad on Windows. Judging by your example, Windows checks whether
> > the code page is present but not whether it is sane for the base locale.
> >
Tom Lane wrote
> That still leaves us with the problem of how to tell whether a locale
> spec is bad on Windows. Judging by your example, Windows checks whether
> the code page is present but not whether it is sane for the base locale.
> What happens when there's a mismatch --- eg, what encoding d
Dave Page <[EMAIL PROTECTED]> writes:
> ... There is another issue
> though as I mentioned in the post above - that it complains about an
> invalid encoding specifier on the encoding name, then ignores it and
> uses the default which seems wrong to me.
Yeah, if you look at chklocale() in initdb.c
Dave Page <[EMAIL PROTECTED]> writes:
> In fact, it looks like it'll allow me to use anything thats installed,
> regardless of whether they're liekly to be compatible. So much for
> trusting setlocale() :-(
Yech :-(. Count on Microsloth to get this wrong. Anyone have any ideas
on how to tell if
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> OK so I added the appropriate entries (and posted the patch to
>> -patches), but my original question remains: why can I only select the
>> *default* encoding for the chosen locale, but not other ones that are
>> also be valid according to
Dave Page <[EMAIL PROTECTED]> writes:
> OK so I added the appropriate entries (and posted the patch to
> -patches), but my original question remains: why can I only select the
> *default* encoding for the chosen locale, but not other ones that are
> also be valid according to setlocale? Is this a b
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Are you certain that that acceptance actually represents support?
>>> Have you checked that it rejects combinations involving real code
>>> pages (ie, NOT 65001) that don't really work with the locale?
>
>> It fails wit
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Are you certain that that acceptance actually represents support?
>> Have you checked that it rejects combinations involving real code
>> pages (ie, NOT 65001) that don't really work with the locale?
> It fails with ones that Microsoft hav
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> However, setlocale() will also accept other valid combinations on
>> Windows, which initdb will not, for example:
>> "English_United Kingdom.28591" (Latin1)
>> Is there any reason not to accept other combinations that setlocale() is
>> happ
Peter Eisentraut wrote:
> Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
>> my original question remains: why can I only select the
>> *default* encoding for the chosen locale, but not other ones that are
>> also be valid according to setlocale? Is this a bug, or is there some
>> technical reason
Dave Page <[EMAIL PROTECTED]> writes:
> However, setlocale() will also accept other valid combinations on
> Windows, which initdb will not, for example:
> "English_United Kingdom.28591" (Latin1)
> Is there any reason not to accept other combinations that setlocale() is
> happy with?
Are you certai
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
> my original question remains: why can I only select the
> *default* encoding for the chosen locale, but not other ones that are
> also be valid according to setlocale? Is this a bug, or is there some
> technical reason?
One locale works only with
Dave Page wrote:
> Peter Eisentraut wrote:
>> Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
>>> So is it just a case of us generating a list of matches that may be
>>> Windows specific, or is there more to it than that?
>> You want to peruse src/port/chklocale.c. There is already explicit Windo
Peter Eisentraut wrote:
> Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
>> So is it just a case of us generating a list of matches that may be
>> Windows specific, or is there more to it than that?
>
> You want to peruse src/port/chklocale.c. There is already explicit Windows
> support in the
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
> So is it just a case of us generating a list of matches that may be
> Windows specific, or is there more to it than that?
You want to peruse src/port/chklocale.c. There is already explicit Windows
support in there, so maybe you just need to add
Peter Eisentraut wrote:
> Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
>> Latin1 is a perfectly valid encoding for my locale English_United
>> Kingdom. It is accepted by setlocale for LC_ALL.
>>
>> Why does initdb reject it? Why does it insist the encoding is not valid
>> for the locale?
>
> B
Am Mittwoch, 10. Oktober 2007 schrieb Dave Page:
> Latin1 is a perfectly valid encoding for my locale English_United
> Kingdom. It is accepted by setlocale for LC_ALL.
>
> Why does initdb reject it? Why does it insist the encoding is not valid
> for the locale?
Because initdb works with a finite l
Peter Eisentraut wrote:
> Dave Page wrote:
>> setlocale(LC_CTYPE, "English_United Kingdom.65001")
>>
>> will return null (and not change anything) because it doesn't like
>> the combination of the locale and that encoding (UTF-8).
>
> The reason that that call fails is probably that the operating
Dave Page wrote:
> setlocale(LC_CTYPE, "English_United Kingdom.65001")
>
> will return null (and not change anything) because it doesn't like
> the combination of the locale and that encoding (UTF-8).
The reason that that call fails is probably that the operating system
does not provide such a lo
Peter Eisentraut wrote:
> Dave Page wrote:
>> Is there any reason not to accept other combinations that setlocale()
>> is happy with?
>
> setlocale() sets the locale. How does it "accept" a "combination"?
>
setlocale(LC_CTYPE, "English_United Kingdom.65001")
will return null (and not change an
Dave Page wrote:
> Is there any reason not to accept other combinations that setlocale()
> is happy with?
setlocale() sets the locale. How does it "accept" a "combination"?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
I'm working on some code for pgInstaller that will check the locale and
encoding selected by the user are a valid combination.
The changes recently added to initdb (which highlighted the UTF-8 issue
on Windows that Tom posted about) appear to only allow the default
encoding for the locale to be se
Thead added to TODO.detail.
---
Tatsuo Ishii wrote:
> > 3. Compiled locale files are large. One UTF-8 locale datafile can
> > exceed a megabyte. Do we want the option of disabling it for small
> > systems?
>
> To avoid the
Greg Stark <[EMAIL PROTECTED]> writes:
> I think it's sheer madness to try to reproduce large swaths of the OS
> inside Postgres because you're unhappy with the quality of the OS
> implementation. You should be asking yourself why OS vendors have such
> a hard time getting this stuff right
In the
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> To be honest, I don't understand why we have to rely on (often broken)
> system locales. I don't think building our own locale data is too
> hard, and once we make up it, the maintenace cost will be very small
> since it should not be changed regularly.
On Sun, Sep 04, 2005 at 10:25:36PM +0900, Tatsuo Ishii wrote:
> > 3. Compiled locale files are large. One UTF-8 locale datafile can
> > exceed a megabyte. Do we want the option of disabling it for small
> > systems?
>
> To avoid the problem, you could dynmically load the compiled
> tables. The cha
> 3. Compiled locale files are large. One UTF-8 locale datafile can
> exceed a megabyte. Do we want the option of disabling it for small
> systems?
To avoid the problem, you could dynmically load the compiled
tables. The charset conversion tables are handled similar way.
Also I think it's importa
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The results were
>> In C locale, SQL_ASCII encoding: 820 ms
>> In C locale, UNICODE encoding: 825 ms
>> Using Dawid's functions: 62010 ms
>> Stripped-down functions: 21010 ms
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> >
> > So it's slow but not spectacularly awful.
>
> glibc is not the world.
Sorry, I should have said "It's not *necessarily* spectacularly awful"
> I tried Dawid's functions on Mac OS X, being a
> random non-glib
Greg Stark <[EMAIL PROTECTED]> writes:
> On Sat, 22 Jan 2005 17:09:42 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I would imagine that the performance is spectacularly awful :-(.
>> Have you benchmarked it? A large sort on a unitext column,
>> for instance, would be revealing.
> Why do you pers
> On Sat, 22 Jan 2005 17:09:42 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > This time setlocale() was needed to get the behaviour
> > > I needed (database initdb'ed to 'C', my order set to 'pl_PL',
> > > or whatever locale I need at given moment).
> > I would imagine that the performance is sp
On Sat, 22 Jan 2005 17:09:42 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > This time setlocale() was needed to get the behaviour
> > I needed (database initdb'ed to 'C', my order set to 'pl_PL',
> > or whatever locale I need at given moment).
> I would imagine that the performance is spectacularly
Dawid Kuroczko <[EMAIL PROTECTED]> writes:
> So... I thoght, why not use this unitext to sort texts?
> So I've created functions, operators and operator class,
> This time setlocale() was needed to get the behaviour
> I needed (database initdb'ed to 'C', my order set to 'pl_PL',
> or whatever local
Hello!
One of least liked by me features of PostgreSQL is a need to specify
LC_CTYPE an LC_COLLATE at initdb time. Especially if you intend to
put into DB texts in
different languages (say, Polish, French, German and Russian) and use
functions like lower() or ORDER BY these texts. :)
I guess the
[EMAIL PROTECTED] writes:
> I have a few people in Europe trying out the rc1 port for OS/2 and they
> have run into a problem with the locale settings
> They have a locale set as de_DE_EURO and the initdb program really does
> not like this because the setlocale(LC_MESSAGES, NULL) call returns a z
Hi
I have a few people in Europe trying out the rc1 port for OS/2 and they
have run into a problem with the locale settings
They have a locale set as de_DE_EURO and the initdb program really does
not like this because the setlocale(LC_MESSAGES, NULL) call returns a zero
length string. When the po
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> * Is it enough to explicitly store/save LC_COLLATE and LC_CTYPE, or does
> more of the locale stuff need to be stored?
The other LC_xxx settings will get fixed by GUC *only* if there are
explicit settings in postgresql.conf ... I don't think you can
Hello!
Here is a temp fix for the locale issues on win32. It passes regression
tests, but is *NOT* ready to be applied (if nothing else, it at least
needs more error checking).
The issue is that locale settings were not inherited by the postgres
backends when they were execed... Instead, the loc
Peter Eisentraut wrote:
> Tom Lane wrote:
> > It's certainly ungood, but I don't think we can materially improve
> > things without a fundamental rewrite along the lines of Peter's
> > proposal to support per-column locale/encoding. Database-level
> > settings are simply the wrong tool for this.
>
Tom Lane wrote:
> It's certainly ungood, but I don't think we can materially improve
> things without a fundamental rewrite along the lines of Peter's
> proposal to support per-column locale/encoding. Database-level
> settings are simply the wrong tool for this.
Well, the complete redo is about t
On Thu, 8 Apr 2004, Tom Lane wrote:
> Yup, exactly. If we did not force both LC_COLLATE and LC_CTYPE to have
> the same values cluster-wide, then we *would* have index corruption
> issues.
We really show warn people that using another encoding in a database then
what the cluster uses, breaks so
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> LC_CTYPE is per cluster and not per database as some of the other LC_.
Yup, exactly. If we did not force both LC_COLLATE and LC_CTYPE to have
the same values cluster-wide, then we *would* have index corruption
issues.
reg
On Thu, 8 Apr 2004, Tom Lane wrote:
> You're missing the point: strcoll() is not going to compare them as
> latin1 strings. It's going to interpret the bytes as utf-8 strings,
> because that's what LC_CTYPE will tell it to do.
My current understanding of what you are saying now is that LC_CTYPE
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 8 Apr 2004, Tom Lane wrote:
>> No, the ordering *will* be the same as it was before, because strcoll()
>> is still functioning the same. You'd get the same answer from a sort
>> operation since it depends on the same operators.
> But, now whe
On Thu, 8 Apr 2004, Tom Lane wrote:
> No, the ordering *will* be the same as it was before, because strcoll()
> is still functioning the same. You'd get the same answer from a sort
> operation since it depends on the same operators.
>
> It interprets them according to LC_CTYPE, which does not ch
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 8 Apr 2004, Tom Lane wrote:
>> See my previous point: the index does not actually fail, in our current
>> implementation, because strcoll() is unaffected by the database's
>> encoding setting.
> How can it be? If I have a utf-8 template1 and a
On Thu, 8 Apr 2004, Tom Lane wrote:
> See my previous point: the index does not actually fail, in our current
> implementation, because strcoll() is unaffected by the database's
> encoding setting.
How can it be? If I have a utf-8 template1 and a table with an index
sorted according to the utf-8
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> I can also imagine the indexes being wrong when you keep the encoding of
> tables when you create a new database. Since the same character can be
> represented differently, the sort order also changes if you try to
> interpret something with another en
> > Are you talking about the sort order? Then there's no problem with
> > encoding itself.
>
> The tables in template1 in encoding E1 are compied into the new database
> in encoding E2. Not all encodings are compatable, so you can't even
> convert from E1 to E2.
In this case you just set your
On Thu, 8 Apr 2004, Tatsuo Ishii wrote:
> > The tables in template1 in encoding E1 are compied into the new database
> > in encoding E2. Not all encodings are compatable, so you can't even
> > convert from E1 to E2.
>
> In this case you just set your terminal encoding to E1, then SELECT
> the t
On Wed, Apr 07, 2004 at 03:40:57PM -0400, Tom Lane wrote:
>
> In practice, we know that we have seen index failures from altering the
> locale settings (back before we installed the code that locks down
> LC_COLLATE/LC_CTYPE at initdb time). I do not recall having heard any
Cannot the same failu
On Thu, 8 Apr 2004, Tatsuo Ishii wrote:
> Are you talking about the sort order? Then there's no problem with
> encoding itself.
The tables in template1 in encoding E1 are compied into the new database
in encoding E2. Not all encodings are compatable, so you can't even
convert from E1 to E2.
--
> On Wed, 7 Apr 2004, Tom Lane wrote:
>
> > If that were so, we'd not have a problem. The reason we have to tread
> > very carefully is that we do not know what tables/indexes users might
> > have added to template1.
>
> Aah, now I see the real problem!
>
> > If we copy a text index into a new
On Wed, 7 Apr 2004, Tom Lane wrote:
> >> solution, which is per-column locale settings within databases.
>
> > Of course, but that solution might be many years ahead.
>
> Peter E. seems to think that it's not an infeasible amount of work.
> (See previous discussion that he mentioned earlier in t
Tom Lane wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
From what I can tell there is only 3 tables we talk about:
pg_database
pg_shadow
pg_group
If that were so, we'd not have a problem. The reason we have to tread
very carefully is that we do not know what tables/indexes users m
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Wed, 7 Apr 2004, Tom Lane wrote:
>> In any case, the whole idea is substantially inferior to the correct
>> solution, which is per-column locale settings within databases.
> Of course, but that solution might be many years ahead.
Peter E. seems to
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Wed, 7 Apr 2004, Tom Lane wrote:
>> If we copy a text index into a new database and claim that it is sorted
>> by some new locale, we'd be breaking things.
> How is this handled for encodings? You can very well have something in
> template1 in an e
On Wed, 7 Apr 2004, Tom Lane wrote:
> If that were so, we'd not have a problem. The reason we have to tread
> very carefully is that we do not know what tables/indexes users might
> have added to template1.
Aah, now I see the real problem!
> If we copy a text index into a new database and claim
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
> > * Allow locale to be set at database creation
>
> BTW, that is redundant with the locale todo items already present.
I see:
* Allow locale to be set at database creation
* Allow locale
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> From what I can tell there is only 3 tables we talk about:
> pg_database
> pg_shadow
> pg_group
If that were so, we'd not have a problem. The reason we have to tread
very carefully is that we do not know what tables/indexes users might
have add
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Allow locale to be set at database creation
BTW, that is redundant with the locale todo items already present.
regards, tom lane
---(end of broadcast)---
T
On Wed, 7 Apr 2004, Tom Lane wrote:
> And even more to the point, it would corrupt non-shared indexes
> inherited from template1. This could not be finessed --- AFAICS you'd
> need to do the equivalent of a REINDEX in the new database to make it
> work.
>From what I can tell there is only 3 tabl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Because that would corrupt indexes on shared tables. (It might be
>> possible to finesse that, but it's not a no-brainer.)
> Oh, I hadn't thought of that. The problem isn't encoding, because we
> handle that already, but differen rep
I said:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I was asking why we can't set it to a new static value when we create
>> the database.
> Because that would corrupt indexes on shared tables. (It might be
> possible to finesse that, but it's not a no-brainer.)
And even more to the point, it
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was asking why we can't set it to a new static value when we create
> > the database.
>
> Because that would corrupt indexes on shared tables. (It might be
> possible to finesse that, but it's not a no-brainer.)
Oh, I hadn't thoug
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was asking why we can't set it to a new static value when we create
> the database.
Because that would corrupt indexes on shared tables. (It might be
possible to finesse that, but it's not a no-brainer.)
regards, tom lane
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Anyone know why we don't allow locale to be set per database?
>
> Changing it on the fly would corrupt index sort ordering. See also
> Peter's response nearby.
I was asking why we can't set it to a new static value when we create
th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Anyone know why we don't allow locale to be set per database?
Changing it on the fly would corrupt index sort ordering. See also
Peter's response nearby.
regards, tom lane
---(end of broadcast)--
Bruce Momjian wrote:
Dennis Bjorklund wrote:
Is anyone working to make the locale support in pg better? Running initdb
to set the locale is a bit heavy. It would be nice to at least be able to
set it per database.
Uh, createdb and CREATE DATABASE both have encoding options. initdb
only s
Dennis Bjorklund wrote:
> Is anyone working to make the locale support in pg better? Running
> initdb to set the locale is a bit heavy. It would be nice to at least
> be able to set it per database.
I was supposed to do that but I got distracted. I send out a longish
implementation and transitio
Dennis Bjorklund wrote:
> Is anyone working to make the locale support in pg better? Running initdb
> to set the locale is a bit heavy. It would be nice to at least be able to
> set it per database.
Oops, I confused locale and multibyte. Yes, I don't see a way to change
locale for new databases,
Dennis Bjorklund wrote:
> Is anyone working to make the locale support in pg better? Running initdb
> to set the locale is a bit heavy. It would be nice to at least be able to
> set it per database.
Uh, createdb and CREATE DATABASE both have encoding options. initdb
only sets the encoding for te
Is anyone working to make the locale support in pg better? Running initdb
to set the locale is a bit heavy. It would be nice to at least be able to
set it per database.
--
/Dennis Björklund
---(end of broadcast)---
TIP 6: Have you searched our li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 15 Dec 2003, Tom Lane wrote:
> > As you can see "I" in "VOID" gets converted to i-dotless in conformance
> > to tr_TR Locale conversion rules, which is not an expected behaviour for
> > Turkish users who set their locale to tr_TR.
>
> W
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> Now, PostgreSQL 7.4 initdb fails if run with locale set to tr_TR:
Ugh :-(
> As you can see "I" in "VOID" gets converted to i-dotless in conformance
> to tr_TR Locale conversion rules, which is not an expected behaviour for
> Turkish users who set their
Hi,
A year ago Nicolai Tufar <[EMAIL PROTECTED]> submitted a patch to
change lower-case conversion of identifiers from locale-dependent to
ASCII in this thread:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg01159.php
Tom Lane argued that SQL99 standard states that identifier case
conv
- Original Message -
From: "Hannu Krosing" <[EMAIL PROTECTED]>
To: "Nicolai Tufar" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, November 30, 2002 5:41 PM
Subject: Re: [HACKERS] Locale-dependent case conversion in {identifier}
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Historically programs that operate in Turkish locale have
> chosen to hardcode the capitalisation of "i" in system
> messages and identifier names like this:
> Lower: "I" -> "i" and "Y'" -> "i".
> Upper: "y'" -> "I" and "i" -> "I".
If that's the behavi
On Sat, 2002-11-30 at 07:57, Nicolai Tufar wrote:
> With this, no matter what kind of "I" you used in names,
> it is always going to end up a valid ASCII character.
>
> Would it be acceptable if I submit a path that applies this
> special logic in src/backend/parser/scan.l if the locale is "tr_TR"
On Sat, 2002-11-30 at 01:40, Nicolai Tufar wrote:
> And I happen to have bad luck to use PostgreSQL with Turkish locale. And, as
> you
> may know our "I" is not your "I":
>
> pgsql=# create table a(x char(1));
> CREATE TABLE
> pgsql=# grant SELECT ON a to PUBLIC;
> ERROR: user "pu
By no means I would try to convince that your reading of
the SQL standards is wrong. What I am trying to tell is
that Turkish alphabet is broken beyond repair. And since
there is absolutely no way to change our alphabet, we
may can code a workaround in the code.
So i do not claim that your code is
1 - 100 of 154 matches
Mail list logo
