Thread: Czech Win1250 sorting q
Hi, ISO-8851-2 Czech support (esp. sorting) works fine, but my data use Win1250. PG 6.5.1+ is supposed to support it, can some kind soul tell me how can I use it? Thanks. - Robert P.S. This is Linux / RH6.1 with Windows clients (browsers). ************
>>>> "Robert" == Robert <robert@robert.cz> writes:
Robert> Hi, ISO-8851-2 Czech support (esp. sorting) works fine, but my
Robert> data use Win1250. PG 6.5.1+ is supposed to support it, can some
Robert> kind soul tell me how can I use it? Thanks.
Robert> - Robert
Just do:
set client encoding to 'WIN1250';
Server will store its data in iso-8859-2, but will recode input and
output for windoze clients.
The reason is, that postgres database server uses locales to sort tables
and there is no 'cs_CZ.WIN-1250' locale - and I hope, that never will be.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@penguin.cz (mime compatible)
************
************
netkof=> show client encoding; ERROR: parser: parse error at or near "encoding" netkof=> set client encoding to 'WIN1250'; ERROR: parser: parse error at or near "encoding" netkof=> set client-encoding to 'WIN1250'; ERROR: parser: parse error at or near "-" Hmm, what did you say I should write? Well, this is PG6.5.2 installed from RPM, should it be compiled with some special option? Thanks. - Robert David Sauer wrote: > >>>> "Robert" == Robert <robert@robert.cz> writes: > > Robert> Hi, ISO-8851-2 Czech support (esp. sorting) works fine, but my > Robert> data use Win1250. PG 6.5.1+ is supposed to support it, can some > Robert> kind soul tell me how can I use it? Thanks. > > Robert> - Robert > > Just do: > > set client encoding to 'WIN1250'; > > Server will store its data in iso-8859-2, but will recode input and > output for windoze clients. > > The reason is, that postgres database server uses locales to sort tables > and there is no 'cs_CZ.WIN-1250' locale - and I hope, that never will be. > > -- > * David Sauer, student of Czech Technical University > * electronic mail: davids@penguin.cz (mime compatible)
>>>> "Robert" == Robert <robert@robert.cz> writes:
Robert> netkof=> show client encoding;
Robert> ERROR: parser: parse error at or
Sorry, my mistake. The right name is 'client_encoding' (with underscore).
Example:
david=> set client_encoding to 'latin2';
SET VARIABLE
Robert> Hmm, what did you say I should write? Well, this is PG6.5.2
Robert> installed from RPM, should it be compiled with some special
Robert> option? Thanks.
Yes, postgres must be compiled with --enable-locale and --with-mb=LATIN2.
And, I'am not sure, but may want upgrade to 6.5.3.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@penguin.cz (mime compatible)
************
I've upgraded to 6.5.3 from RPM but 'set client_encoding' still says 'unknow variable'. How can I know whether RPM was compiled with --enable-locale and --with-mb=LATIN2? And if it wasn't, could I humbly suggest it for next version? If I knew it wasn't compiled with the right options, I could just take a deep breath and try to recompile it myself. However, there's no info about compile options used to prepare RPM and I'm not sure I'm not doing some trivial mistake... I'd like to avoid recompiling the whole thing if I can. - Robert P.S. David, thanks for your help so far. I forgot to send my last mail to the list and sent it to your address only instead. Sorry. David Sauer wrote: > >>>> "Robert" == Robert <robert@robert.cz> writes: > > Robert> netkof=> show client encoding; > Robert> ERROR: parser: parse error at or > > Sorry, my mistake. The right name is 'client_encoding' (with underscore). > > Example: > > david=> set client_encoding to 'latin2'; > SET VARIABLE > > Robert> Hmm, what did you say I should write? Well, this is PG6.5.2 > Robert> installed from RPM, should it be compiled with some special > Robert> option? Thanks. > > Yes, postgres must be compiled with --enable-locale and --with-mb=LATIN2. > And, I'am not sure, but may want upgrade to 6.5.3. > > -- > * David Sauer, student of Czech Technical University > * electronic mail: davids@penguin.cz (mime compatible) > > ************
Robert wrote: > > I've upgraded to 6.5.3 from RPM but 'set client_encoding' still says > 'unknow variable'. How can I know whether RPM was compiled > with --enable-locale and --with-mb=LATIN2? And if it wasn't, > could I humbly suggest it for next version? The default 6.5.3-2 RPM's are compiled with --enable-locale, but not with --with-mb=LATIN2. (NOTE: The following procedure tells how to rebuild the RPM set. Before doing so, make sure you have a full development system -- C and C++ compilers, Tcl/Tk (and by extension X11), python-devel, perl, and the latest rpm (rpm-3.0.2 or 3.0.3).) To change that, get the postgresql-6.5.3-2.src.rpm from my site (http://www.ramifordistat.net/postgres), and do the following (as root): 1.) rpm -i postgresql-6.5.3-2.src.rpm 2.) cd /usr/src/redhat/SPECS 3.) Open postgresql-6.5.3-2.spec in your favorite editor. 4.) Find the line with configure, but not the one inside the alpha conditional. 5.) Change the options as you need. 6.) Change the line starting with Release: to be something other than 2 -- maybe '2cz' is good. This line is near the top. 7.) Save and close the spec file. 8.) Rename the spec file to be like the Release -- for a Release of '2cz', make the file 'postgresql-6.5.3-2cz.spec -- this helps prevent confusion. 9.) Execute 'rpm -ba postgresql-6.5.3-2cz.spec' -- this should, if you have all the needed compilers and development libraries installed, build the package, and create the binary rpms in the directory /usr/src/redhat/RPMS/i386 (assuming you're compiling for i386). 10.) You can now install the binary RPMs that you have just built. HTH -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Re: With what options RPM was compiled? ( Was: Czech Win1250 sorting q)
From
Peter Eisentraut
Date:
On 1999-12-13, Lamar Owen mentioned: > The default 6.5.3-2 RPM's are compiled with --enable-locale, but not > with --with-mb=LATIN2. Perhaps the next set of RPMs could be compiled with --enable-locale and --with-mb=SQL_ASCII. At least do it like now: the non-locale/non-multibyte version for performance, and the locale/mb version for features. Please note that SQL_ASCII doesn't mean that the db cannot support any other encoding, it's just the default encoding initdb uses. The questioner could then use this RPM and initialize with initdb -e LATIN2, if he chooses. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Re: [GENERAL] Re: With what options RPM was compiled? ( Was: CzechWin1250 sorting q)
From
Lamar Owen
Date:
Peter Eisentraut wrote: > > On 1999-12-13, Lamar Owen mentioned: > > > The default 6.5.3-2 RPM's are compiled with --enable-locale, but not > > with --with-mb=LATIN2. > > Perhaps the next set of RPMs could be compiled with --enable-locale and > --with-mb=SQL_ASCII. At least do it like now: the non-locale/non-multibyte > version for performance, and the locale/mb version for features. Please > note that SQL_ASCII doesn't mean that the db cannot support any other > encoding, it's just the default encoding initdb uses. That's a thought. On my TODO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
>>>> "Robert" == Robert <robert@robert.cz> writes:
Robert> Hi, ISO-8851-2 Czech support (esp. sorting) works fine, but my
Robert> data use Win1250. PG 6.5.1+ is supposed to support it, can some
Robert> kind soul tell me how can I use it? Thanks.
Robert> - Robert
Just do:
set client encoding to 'WIN1250';
Server will store its data in iso-8859-2, but will recode input and
output for windoze clients.
The reason is, that postgres database server uses locales to sort tables
and there is no 'cs_CZ.WIN-1250' locale - and I hope, that never will be.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@penguin.cz (mime compatible)
************
************
Thanks for everybody's help, I got it working now. An observation: The steps Lamar described really created a binary RPM, however the pg_encoding utility isn't included (it was built though). Similarly 'createdb -E LATIN2 xx' from README.mb doesn't work, while create database with encoding = 'latin2' works OK. - Robert PS If anybody's is in urgent need, I can put those rpms online before Lamar builts the new version with multibyte support enabled - just let me know you're interested. Lamar Owen wrote: > Robert wrote: > > > > I've upgraded to 6.5.3 from RPM but 'set client_encoding' still says > > 'unknow variable'. How can I know whether RPM was compiled > > with --enable-locale and --with-mb=LATIN2? And if it wasn't, > > could I humbly suggest it for next version? > > The default 6.5.3-2 RPM's are compiled with --enable-locale, but not > with --with-mb=LATIN2. > > (NOTE: The following procedure tells how to rebuild the RPM set. Before > doing so, make sure you have a full development system -- C and C++ > compilers, Tcl/Tk (and by extension X11), python-devel, perl, and the > latest rpm (rpm-3.0.2 or 3.0.3).) > ...
Robert wrote: > > Thanks for everybody's help, I got it working now. An observation: > The steps Lamar described really created a binary RPM, however > the pg_encoding utility isn't included (it was built though). Can be added to the %files list easily enough. Will be included in next release. > Similarly > 'createdb -E LATIN2 xx' from README.mb doesn't work, while > create database with encoding = 'latin2' works OK. Hmmm... Reading the createdb script shows that the pg_encoding utility is used by createdb.... Hopefully will be fixed next release. > PS If anybody's is in urgent need, I can put those rpms online before > Lamar builts the new version with multibyte support enabled - just let > me know you're interested. I can rebuild overnight tonight, if need be. I have a few other items on the rebuild plate anyway. Prep for the release of 6.5.3-3.....coming soon to an ftp server near you. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Re: With what options RPM was compiled? ( Was: CzechWin1250 sorting q)
From
Lamar Owen
Date:
Peter Eisentraut wrote: > > On 1999-12-13, Lamar Owen mentioned: > > > The default 6.5.3-2 RPM's are compiled with --enable-locale, but not > > with --with-mb=LATIN2. > > Perhaps the next set of RPMs could be compiled with --enable-locale and > --with-mb=SQL_ASCII. At least do it like now: the non-locale/non-multibyte > version for performance, and the locale/mb version for features. Please > note that SQL_ASCII doesn't mean that the db cannot support any other > encoding, it's just the default encoding initdb uses. With version 6.5.3, setting --with-mb=SQL_ASCII throws a configure error. It then lists the valid encodings, which do not include SQL_ASCII. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
In the event of a hardware failure or some other problem potentially corrupting a postgres database, how does one verify the integrity of the database with certainty before resuming operations?
Re: [GENERAL] Re: With what options RPM was compiled? ( Was: CzechWin1250 sorting q)
From
Peter Eisentraut
Date:
On 1999-12-14, Lamar Owen mentioned: > With version 6.5.3, setting --with-mb=SQL_ASCII throws a configure > error. It then lists the valid encodings, which do not include > SQL_ASCII. Thank you very much. This was one of the reasons I wanted this changed to --enable-mb, but some people really wanted that default encoding there. Complain to them. :) That will be fixed for the next release. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
After following some hints from Bruce Momjian and the pgsql documentation, I'm still missing something on how to get timestamped backend logging from pgsql...any help is appreciated... After running ./configure, I modifed ...src/include/config.h to uncomment the two lines... #define ELOG_TIMESTAMPS #define USE_SYSLOG Then I ran make, etc, created the file $PGDATA/pg_options... % cat $PGDATA/pg_options verbose=2 query syslog=2 And restarted the server...and still no timestamps. I verified most everything syslog-wise (configured in /etc/syslog.conf) is being sent to /var/log/messages... Anyone notice what am I missing? Cheers, Ed Loehr
>>>> "Robert" == Robert <robert@robert.cz> writes:
Robert> Hi, ISO-8851-2 Czech support (esp. sorting) works fine, but my
Robert> data use Win1250. PG 6.5.1+ is supposed to support it, can some
Robert> kind soul tell me how can I use it? Thanks.
Robert> - Robert
Just do:
set client encoding to 'WIN1250';
Server will store its data in iso-8859-2, but will recode input and
output for windoze clients.
The reason is, that postgres database server uses locales to sort tables
and there is no 'cs_CZ.WIN-1250' locale - and I hope, that never will be.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@penguin.cz (mime compatible)
************
************
>>>> "Robert" == Robert <robert@robert.cz> writes:
Robert> netkof=> show client encoding;
Robert> ERROR: parser: parse error at or
Sorry, my mistake. The right name is 'client_encoding' (with underscore).
Example:
david=> set client_encoding to 'latin2';
SET VARIABLE
Robert> Hmm, what did you say I should write? Well, this is PG6.5.2
Robert> installed from RPM, should it be compiled with some special
Robert> option? Thanks.
Yes, postgres must be compiled with --enable-locale and --with-mb=LATIN2.
And, I'am not sure, but may want upgrade to 6.5.3.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@penguin.cz (mime compatible)
************
On Mon, 13 Dec 1999, David Sauer wrote: > Robert> Hmm, what did you say I should write? Well, this is PG6.5.2 > Robert> installed from RPM, should it be compiled with some special > Robert> option? Thanks. > > Yes, postgres must be compiled with --enable-locale and --with-mb=LATIN2. > And, I'am not sure, but may want upgrade to 6.5.3. The pg_encoding utility is not shipped with any RPM's prior to 6.5.3-3 -- I would say that upgrading to that would be a good thing. Also, prior to 6.5.3-3, the RPM distribution, while compiled with --enable-locale, was not compiled with --with-mb= -- thus, while the RPM binaries have locale support, they don't have multibyte, which may be needed. The 6.5.3-3 RPM's fix that. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11