Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

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

Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

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)

Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

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

Re: [HACKERS] Locale dependency in new postgres_fdw test

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

Re: [HACKERS] Locale dependency in new postgres_fdw test

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

Re: [HACKERS] Locale dependency in new postgres_fdw test

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

Re: [HACKERS] locale operation to be invoked, but no collation was derived (in trigger)

Stefan Huehner ste...@huehner.org 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

Re: [HACKERS] locale operation to be invoked, but no collation was derived (in trigger)

Stefan Huehner ste...@huehner.org 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

Re: [HACKERS] Locale, Collation, ICU patch

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 can

Re: [HACKERS] Locale, Collation, ICU patch

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 can

Re: [HACKERS] Locale, Collation, ICU patch

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

Re: [HACKERS] Locale vs LIKE

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!

Re: [HACKERS] Locale + encoding combinations

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 code page is

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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 do

Re: [HACKERS] Locale + encoding combinations

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 after

Re: [HACKERS] Locale + encoding combinations

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 system

Re: [HACKERS] Locale + encoding combinations

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 list

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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 there, so

Re: [HACKERS] Locale + encoding combinations

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 Windows

Re: [HACKERS] Locale + encoding combinations

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 one

Re: [HACKERS] Locale + encoding combinations

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 certain that

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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 happy with? Are

Re: [HACKERS] Locale + encoding combinations

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 have decided

Re: [HACKERS] Locale + encoding combinations

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 with ones that

Re: [HACKERS] Locale + encoding combinations

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 bug,

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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 a

Re: [HACKERS] Locale + encoding combinations

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 this

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale + encoding combinations

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 anything)

Re: [HACKERS] Locale + encoding combinations

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

Re: [HACKERS] Locale implementation questions

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

Re: [HACKERS] Locale implementation questions

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 important

Re: [HACKERS] Locale implementation questions

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 charset

Re: [HACKERS] Locale implementation questions

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.

Re: [HACKERS] Locale implementation questions

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 case

Re: [HACKERS] Locale agnostic unicode text

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

Re: [HACKERS] Locale agnostic unicode text

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 persist in

Re: [HACKERS] Locale agnostic unicode text

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-glibc platform

Re: [HACKERS] Locale agnostic unicode text

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 I don't think

Re: [HACKERS] Locale agnostic unicode text

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 awful

Re: [HACKERS] Locale agnostic unicode text

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 locale I

Re: [HACKERS] Locale question

[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 zero

Re: [HACKERS] locale issues on win32 (fix?)

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

Re: [HACKERS] locale

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 two

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 failure

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 table

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 when we

Re: [HACKERS] locale

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 is

Re: [HACKERS] locale

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.

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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,

Re: [HACKERS] locale

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 transition

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 the

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 thought of

Re: [HACKERS] locale

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 would

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 tables

Re: [HACKERS] locale

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)--- TIP

Re: [HACKERS] 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 added to

Re: [HACKERS] locale

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 on a

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 encoding

Re: [HACKERS] locale

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 think

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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 this

Re: [HACKERS] locale

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

Re: [HACKERS] locale

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

Re: [HACKERS] Locale-based identifier conversion and Turkish

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 locale to

Re: [HACKERS] Locale-dependent case conversion in {identifier}

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 public does

Re: [HACKERS] Locale-dependent case conversion in {identifier}

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?

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 behavior you want, why don't you

Re: [HACKERS] Locale-dependent case conversion in {identifier}

- 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} [ ... ] could it just be that we store

Re: [HACKERS] Locale-dependent case conversion in {identifier}

Nicolai Tufar [EMAIL PROTECTED] writes: So I have changed lower-case conversion code in scan.l to make it purely ASCII-based. as in keywords.c. Mini-patch is given below. Rather than offering a patch, you need to convince us why our reading of the SQL standard is wrong. (Oracle does it that

Re: [HACKERS] Locale-dependent case conversion in {identifier}

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

Re: [HACKERS] Locale number format confusion

On Thu, Aug 08, 2002 at 11:19:04PM +0200, Peter Eisentraut wrote: It seems we need a smart plan for handling the decimal point vs. comma issue. Observe: (lc_numeric = de_DE) ^^ It seems like hellish toy... :-) Karel -- Karel Zak [EMAIL PROTECTED]

Re: [HACKERS] Locale number format confusion

Peter Eisentraut [EMAIL PROTECTED] writes: I propose that we do this (probably by writing our own strtod and friends). If you want to format your numbers to local convention, to_char() can be used. Why are we allowing LC_NUMERIC to become active at all? IMHO this is a bug that you have

Re: [HACKERS] Locale support is now on by default

Tom Lane writes: initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG initdb --no-locale is the same as initdb --locale=C, for convenience. I'm confused; what is the default behavior if you don't give any switches to initdb? Whatever is set in the environment -- which boils

Re: [HACKERS] Locale support is now on by default

Tom Lane writes: It might be that Bruce's recent changes to elog levels allow a graceful compromise about backend messages during initdb. I haven't looked, but maybe initdb could run the backend with message level one notch higher than LOG to suppress all the normal-case messages without

Re: [HACKERS] Locale support is now on by default

Peter Eisentraut [EMAIL PROTECTED] writes: I was thinking about handling this within initdb, with a display like this: The files belonging to this database system will be owned by user peter. This user must also own the server process. Locale settings: collate=en_US ctype=en_US [...]

Re: [HACKERS] Locale support is now on by default

BTW, I still suggest changing initdb to set message_level = FATAL rather than /dev/null'ing the output. Having to use -d to learn anything at all about the cause of an initdb-time failure is a pain in the neck. This is a great idea. Certainly there are FATAL/PANIC messages during initdb

Re: [HACKERS] Locale support is now on by default

Bruce Momjian writes: There doesn't seem to be a way to turn off LOG without hiding almost everything: if (lev == LOG || lev == COMMERROR) { if (server_min_messages == LOG) output_to_server = true; else if (server_min_messages

Re: [HACKERS] Locale support is now on by default

Peter Eisentraut wrote: Bruce Momjian writes: There doesn't seem to be a way to turn off LOG without hiding almost everything: if (lev == LOG || lev == COMMERROR) { if (server_min_messages == LOG) output_to_server = true; else

Re: [HACKERS] Locale support is now on by default

Bruce Momjian writes: Server levels are: # debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, panic I don't recall log being so high. Didn't it use to be after info? Certainly there should be a way to see only

Re: [HACKERS] Locale support is now on by default

Peter Eisentraut wrote: Bruce Momjian writes: Server levels are: # debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, panic I don't recall log being so high. Didn't it use to be after info? Certainly there

Re: [HACKERS] Locale support is now on by default

Bruce Momjian writes: If you would prefer LOG down near INFO in the server message levels, please post the idea and let's get some more comments from folks. LOG should be below WARNING, in any case. Perhaps between NOTICE and WARNING, but I'm not so sure about that. -- Peter Eisentraut

  1   2   >