Re: [HACKERS] src/timezone/pgtz __imp__my_exec_path
postgresql-cygwin is working fine. See the testfarm. Just cygwin itself, cygserver - the IPC daemon - has problems. On msgctl(IPC_INFO) the internal msg buffer struct msqid_ds *buf is allocated at a non-writable area, IsBadWritePtr() fails. I suspect it's a new gcc-3.4 feature, but haven't found the problem yet. gcc-3.3 fails also. (these don't have dwarf-2 support yet, just sjlj. cygwin itself is c++ and uses exceptions heavily.) It works for most users out there, but not for me, this is why I didn't did a proper beta5 cygwin release yet. A pity that no one else can confirm my cygserver problems yet. And I got beta4 on a fairly busy server working only with max-connection=2, not more. Bruce Momjian schrieb: Is Cygwin now working properly in CVS and beta5? I assume so. --- Magnus Hagander wrote: beta4 - cygwin: postgres.exe fails to build, because __imp__my_exec_path from src/timezone/pgtz.o cannot be resolved. previously it was not imported. This could be related to the patch that went in last weekend to fix compiles on Win32. DLLIMPORT was added to the header. If the Makefile did not change, then that is your problem - that patch changed botht he makefile and the header. See http://archives.postgresql.org/pgsql-committers/2004-10/msg00321.php Does CYGWIN perhaps need the same Makefile patch? You only patched your Makefile.win32, not Makefile.cygwin. That's it. It builds fine now. Please add also ifneq (,$(findstring timezone,$(subdir))) override CPPFLAGS+= -DBUILDING_DLL endif to the Makefile.cygwin. Without it doesn't break just contrib/tsearch, it even breaks cygwin postmaster. Soudns reasonable. Maybe all win32.mak and bcc32.mak must also be checked. Does anybody do the msvc/borland suites? Not affected. Only the frontend can be compiled with those, and this is a backend change. -- I'm using MozTweak addon, and you? MozTweak: http://www.MozillaPL.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] how to enable syslog in windows
how can i enable syslog in postgresql8.0.0beta4 on windows if syslog_indent,syslog_facility are commented only postgres service is starting if i remove the comment(#) service is not starting can anyone help me out Regards Ganesan SReini Urban [EMAIL PROTECTED] wrote: postgresql-cygwin is working fine. See the testfarm.Just cygwin itself, cygserver - the IPC daemon - has problems.On msgctl(IPC_INFO) the internal msg buffer struct msqid_ds *buf is allocated at a non-writable area, IsBadWritePtr() fails. I suspect it's a new gcc-3.4 feature, but haven't found the problem yet. gcc-3.3 fails also. (these don't have dwarf-2 support yet, just sjlj. cygwin itself is c++ and uses exceptions heavily.)It works for most users out there, but not for me, this is why I didn't did a proper beta5 cygwin release yet. A pity that no one else can confirm my cygserver problems yet.And I got beta4 on a fairly busy server working only with max-connection=2, not more.Bruce Momjian schrieb: Is Cygwin now working properly in CVS and beta5? I assume so. --- Magnus Hagander wrote:beta4 - cygwin:postgres.exe fails to build, because __imp__my_exec_path from src/timezone/pgtz.o cannot be resolved. previously it was not imported.This could be related to the patch that went in last weekend to fix compiles on Win32. DLLIMPORT was added to the header. If the Makefile did not change, then that is your problem - that patch changed botht he makefile and the header. See http://archives.postgresql.org/pgsql-committers/2004-10/msg00321.phpDoes CYGWIN perhaps need the same Makefile patch?You only patched your Makefile.win32, not Makefile.cygwin. That's it. It builds fine now.Please add alsoifneq (,$(findstring timezone,$(subdir))) override CPPFLAGS+= -DBUILDING_DLL endifto the Makefile.cygwin.Without it doesn't break just contrib/tsearch, it even breaks cygwin postmaster.Soudns reasonable.Maybe all win32.mak and bcc32.mak must also be checked. Does anybody do the msvc/borland suites?Not affected. Only the frontend can be compiled with those, and this isa backend change.-- I'm using MozTweak addon, and you? MozTweak: http://www.MozillaPL.org---(end of broadcast)---TIP 6: Have you searched our list archives?http://archives.postgresql.org__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[HACKERS] PostgreSQL testresults
Hello, I have not seen any PostgreSQL mailing-list for posting results of compilation/testing on different platforms/configurations (something similar to gcc-testresults for gcc). Are you guys interested in getting results like this ? It could provide developers with lots of interesting information about errors, warnings and regressions (including build testing times). If you want me to add a little shell script to gather that, I would be glad to do it. It certainly should be on a separate mailing list though (pgsql-testresults ?) Example of a successful build that I did tonight: postgresql-8.0.0beta5 on Fedora Core 3 x86_64 (dual Opteron 2GHz), gcc-3.4.2 :: configure :: CFLAGS=-m64 -g -O2 -march=opteron -fPIC -pipe CXXFLAGS=-m64 -g -O2 -march=opteron -fPIC -pipe LDFLAGS=-m64 -fPIC nohup ./configure --prefix=/opt/pgsql --with-includes=/usr/include/et --with-tcl --with-perl --with-python --with-krb5 --with-pam --with-openssl --enable-nls --enable-thread-safety :: make :: == All of PostgreSQL successfully made. Ready to install. 0 compiler errors 21 compiler warnings == $ time make -j 2 real1m30.094s user2m11.038s sys 0m13.771s :: make check :: == All 96 tests passed. == $ time make -j 2 check real0m39.843s user0m15.770s sys 0m12.490s Build times are not bad :-) Cheers, Philippe Rigault ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New member says hello
[EMAIL PROTECTED] writes: at 09:50 PM, Tom Lane [EMAIL PROTECTED] said: If you're hoping to get this into 8.0, it had better arrive soon and be a very small patch ... It may have to be for 8.0.1 there are a lot of changes to the makefiles to accomodate the if(($portname), ibmos2) stuff and the src/port/ibmos2 code More like 8.1, then. A not-previously-supported port is going to be seen as a new feature, not a bug fix, especially if the changes are less than trivial. BTW - has anyone else noticed that there are a number of places where there is a test for HAVE_OPTRESET instead of HAVE_INT_OPTRESET? Good catch ... that's definitely broken. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] how to enable syslog in windows
Ganesan S [EMAIL PROTECTED] writes: how can i enable syslog in postgresql8.0.0beta4 on windows Has Windows got syslog? I thought not. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New member says hello
In [EMAIL PROTECTED], on 11/27/04 at 01:05 PM, Tom Lane [EMAIL PROTECTED] said: [EMAIL PROTECTED] writes: at 09:50 PM, Tom Lane [EMAIL PROTECTED] said: If you're hoping to get this into 8.0, it had better arrive soon and be a very small patch ... It may have to be for 8.0.1 there are a lot of changes to the makefiles to accomodate the if(($portname), ibmos2) stuff and the src/port/ibmos2 code More like 8.1, then. A not-previously-supported port is going to be seen as a new feature, not a bug fix, especially if the changes are less than trivial. Sounds good to me... The makefile changes are more than trivial (18 new and/or changed files) and the build environment would have to be tested on supported platforms to make sure nothing got broken. There are a few changes to the C code (28 new and/or changed files) and H files (9 new and/or changed files). So far :-) BTW - has anyone else noticed that there are a number of places where there is a test for HAVE_OPTRESET instead of HAVE_INT_OPTRESET? Good catch ... that's definitely broken. Sometimes doing a new port finds problems that are not noticed otherwise. I'll just forge ahead with the OS/2 stuff and get patches ready for a post 8.0.0 GA Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL testresults
Philippe Rigault said: Hello, I have not seen any PostgreSQL mailing-list for posting results of compilation/testing on different platforms/configurations (something similar to gcc-testresults for gcc). Are you guys interested in getting results like this ? It could provide developers with lots of interesting information about errors, warnings and regressions (including build testing times). If you want me to add a little shell script to gather that, I would be glad to do it. It certainly should be on a separate mailing list though (pgsql-testresults ?) Have a look at http://www.pgbuildfarm.org cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bitmap index
On Nov 22, 2004, at 2:57 AM, Pawe Niewiadomski wrote: Hello, I saw discussion about bitmap indexes few weeks ago. I wonder if any of you is working on it (in secret)? I will be chosing subject of my master thesis and thougth about implementing bitmap indexes. -- **Pawe Niewiadomski**, new()foo-baz.com, http://new.foo-baz.com/ Podrcznik Administratora Systemu Linux: http://sag.foo-baz.com/ Podrcznik Programisty Systemu Linux: http://lpg.foo-baz.com/ Virtual Qmail (http://v-q.foo-baz.com), qmail-patches (http://q-p.foo-baz.com) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings I have been looking into this myself but have not had the time to attack it. If you are going to pick this up and run with it, please let me know how I can help. This would be a great feature to have for data warehousing. Patrick B. Kelly -- http://patrickbkelly.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] VACUUM FULL FREEZE is unsafe
The point of VACUUM FREEZE is to ensure that there are no tuples present in the database whose commit status depends on normal XIDs. Without this guarantee, cloning template0 might stop working once the relevant part of pg_clog has been pruned. If one combines freezing with moving tuples across pages (ie, VACUUM FULL FREEZE), then the commit status of moved tuples may depend on the vacuum's own XID (stored in XVAC). To maintain the freeze safety guarantee, we'd want to be sure that upon successful completion of the VACUUM, there are no moved tuples that haven't had their status hint bits updated to XMIN_COMMITTED or XMIN_INVALID. After some digging through vacuum.c, I have convinced myself that this does occur for all tuples moved down from the end of the table. update_hint_bits() takes care of all MOVED_IN rows; MOVED_OFF rows in the page that becomes the physically last page of the table are fixed near the bottom of repair_frag(); and MOVED_OFF rows in pages after that don't matter because we'll truncate those pages away entirely. Unfortunately this still leaves one case uncovered, which is a tuple that is moved because it is part of an update chain. If an original tuple in an update chain is in a page that is below the new end of the table, and was not a move target page (eg because it had no free space), then that tuple will never be visited to change its state from MOVED_OFF to XMIN_INVALID. This doesn't break initdb, because there will be no update-chain cases since no other transactions can be running. But it poses a nasty hazard for anyone who is updating and re-freezing a template database during normal operations (as for example in following the manual bug fix procedures we had to recommend for some of the 7.4 dot releases). Also, even though I don't see any failure cases for initdb, it seems awfully risky to assume that this is all going to work 100%; and if initdb did leave any improperly frozen tuples behind, it's quite likely we'd not notice the error until the code got into the field. ISTM that the safer way to handle this is VACUUM FULL (to compact) and then VACUUM FREEZE (to freeze). It's much clearer that lazy VACUUM can handle freezing reliably, because it never tries to move tuples around. Just doing this in initdb is a one-liner change, but I'm wondering if we ought to enforce that FULL and FREEZE not be specified at the same time, so that people couldn't risk such a problem in manual freezing of template databases. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] pg_autovacuum in 8beta-dev3 small bug
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 27 November 2004 04:33 To: [EMAIL PROTECTED] Cc: PostgreSQL Win32 port list; PostgreSQL-development Subject: Re: [pgsql-hackers-win32] [BUGS] pg_autovacuum in 8beta-dev3 small bug Can someone comment on this? -- - Leen Besselink wrote: Hi folks, 8.0beta3 has pg_autovacuum included, when I want to run this as a Windows service, it says you can use the -I and -R options. When I do that and I specify a password with '-P' (uppercase) then in the registry it's saved as '-p' (lowercase) in the service-commandline (ImagePath). This was fixed in v1.21 of pg_autovacuum.c, That rev is tagged for beta3, so you should not be seeing this issue unless you actually have an older version for some reason. http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_autovacuum/p g_autovacuum.c.diff?r1=1.20;r2=1.21;f=h Also it removes the quotes I added and I'm not so sure it would work the way it's supposed to, without it. It's not so much that it strips them (that happens automagically), more that it doesn't re-add them when it writes the command line in the registry. The attached patch fixes that by simply quoting all options that may need it. If you add DependOnService (a REG_MULTI_SZ an array-like-thingie) and have the name (in this case: pgsql-8.0-beta2-dev3) of a service it depends on, it will not fail to start (it will not even try, as PostgreSQL is not running), when PostgreSQL already failed. Maybe it's an idea to specify it on the commandline (what service to depend on). A -E service option is added in the attached patch. Regards, Dave. pg_autovacuum.diff Description: pg_autovacuum.diff ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] how to enable syslog in windows
Tom Lane wrote: Ganesan S [EMAIL PROTECTED] writes: how can i enable syslog in postgresql8.0.0beta4 on windows Has Windows got syslog? I thought not. No, Windows in itself doesn't. The preferred way on windows is to use the event logger. There are of course a number of freeware syslog implementations out there for windows but if the objective is to behave like a normal windows service or app, my advice would be to avoid them. What is the windows port doing today? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] VACUUM FULL FREEZE is unsafe
So why not have VACUUM FULL FREEZE just do what you propose: VACUUM FULL then VACUUM FREEZE. -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005 On Nov 27, 2004, at 3:41 PM, Tom Lane wrote: The point of VACUUM FREEZE is to ensure that there are no tuples present in the database whose commit status depends on normal XIDs. Without this guarantee, cloning template0 might stop working once the relevant part of pg_clog has been pruned. If one combines freezing with moving tuples across pages (ie, VACUUM FULL FREEZE), then the commit status of moved tuples may depend on the vacuum's own XID (stored in XVAC). To maintain the freeze safety guarantee, we'd want to be sure that upon successful completion of the VACUUM, there are no moved tuples that haven't had their status hint bits updated to XMIN_COMMITTED or XMIN_INVALID. After some digging through vacuum.c, I have convinced myself that this does occur for all tuples moved down from the end of the table. update_hint_bits() takes care of all MOVED_IN rows; MOVED_OFF rows in the page that becomes the physically last page of the table are fixed near the bottom of repair_frag(); and MOVED_OFF rows in pages after that don't matter because we'll truncate those pages away entirely. Unfortunately this still leaves one case uncovered, which is a tuple that is moved because it is part of an update chain. If an original tuple in an update chain is in a page that is below the new end of the table, and was not a move target page (eg because it had no free space), then that tuple will never be visited to change its state from MOVED_OFF to XMIN_INVALID. This doesn't break initdb, because there will be no update-chain cases since no other transactions can be running. But it poses a nasty hazard for anyone who is updating and re-freezing a template database during normal operations (as for example in following the manual bug fix procedures we had to recommend for some of the 7.4 dot releases). Also, even though I don't see any failure cases for initdb, it seems awfully risky to assume that this is all going to work 100%; and if initdb did leave any improperly frozen tuples behind, it's quite likely we'd not notice the error until the code got into the field. ISTM that the safer way to handle this is VACUUM FULL (to compact) and then VACUUM FREEZE (to freeze). It's much clearer that lazy VACUUM can handle freezing reliably, because it never tries to move tuples around. Just doing this in initdb is a one-liner change, but I'm wondering if we ought to enforce that FULL and FREEZE not be specified at the same time, so that people couldn't risk such a problem in manual freezing of template databases. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] VACUUM FULL FREEZE is unsafe
Thomas F.O'Connell [EMAIL PROTECTED] writes: So why not have VACUUM FULL FREEZE just do what you propose: VACUUM FULL then VACUUM FREEZE. The objective is to make it more safe, not less so. Doing that would require rewriting a whole bunch of code, which I am not up for at this stage of the release cycle. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Fix for NLS in pgport
I saw Peter's commit to allow NLS lookups from libpgport functions. Here is the change to pg_ctl/nls.mk: GETTEXT_FILES := pg_ctl.c GETTEXT_FILES := pg_ctl.c ../../port/exec.c Peter, do you have to know the C file used by pg_ctl to make these adjustments? This seems pretty hard to do and maintain. Do your tools do checks to make sure all the nls.mk files are properly modified? Is there a cleaner way to do this like putting all the strings in single C file and including that somehow? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Problems using pgxs on Win32
I assume all the pgxs changes have been applied by Tom. --- Fabien COELHO wrote: Dear Thomas, I'm trying to change the Makefile system for PL/Java so that it uses PGXS instead of compiling using a complete PostgreSQL source tree. As it turns out, the directory include/port/win32 is not present in the PostgreSQL binary installation. Without it, it's not possible to compile on win32. Indeed, this directory is not installed by the install target. If it is really needed, it is no big deal. However if done so, it should be under include/server/port/win32/, not include/port/win32, but this should be taken care of by some macro, I guess. Do I need some special configuration in order to get the missing pieces? I guess you're the first one ever to test this under win32;-) You can try to copy by hand the directory into include/server/port/ of your installation, and check whether it is the only issue. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Suggestion: additional system views
This has been saved for the 8.1 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --- David Fetter wrote: On Mon, Nov 01, 2004 at 12:49:47AM +0100, Gaetano Mendola wrote: Josh Berkus wrote: Neil, pg_functions might be useful, but what would pg_users offer that pg_user does not already do? Show a list of groups that the user belongs to? Same thing with pg_groups; showing the list of users in the group. A pg_sequences view might also be handy. Yes. Anything else? So far I have: pg_users pg_groups pg_functions pg_sequences hmmm ... pg_schemas pg_tablespaces ... as well, just for completeness. This is obviously and 8.1 thing, so I'll put it on my task list for after 8.0 PR is done. I suggest to add on pg_functions and on pg_views too, the list of dependencies with other objects. pg_keywords pg_sqlstates Attached is a rough draft of the latter. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql and schemas
Is there a TODO here? Or a few? --- Neil Conway wrote: On Sun, 2004-10-31 at 05:32, Tom Lane wrote: The behaviors you mention were written at different times by different people, and mostly have nothing to do with schemas per se. I agree that some more consistency would probably be good. Do you have a specific proposal? Sure, I just thought I'd check if there was method to psql's madness before suggesting changes. Proposed new behavior: \dn non_existent_schema === No such schema ... (previously: empty list of schemas) \d non_existent_schema.* === No such schema ... (previously: Did not find any relation named non_existent_schema.*.) I'm not sure how we should handle \dn schema_name. (notice the period; assuming a schema with that name exists). The current behavior of listing all schemas is obviously wrong, but I'm not sure what the right behavior is. Perhaps we should reject the command? I think there needs to be a way to list all the objects in a schema. What do people think about making \dn schema behave like \dn+ schema currently does, and changing \dn+ schema to list the objects in the specified schema, like \d currently does for the objects in the search path? (BTW, I think a useful way to assess the usability of psql's schema slash commands is trying to use them to explore the information_schema. Perhaps I'm missing something, but with the current psql it seems almost impossible to do that effectively without adding information_schema to the search path.) -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Non-C locale and LIKE
I know we can't currently use an index with non-C locales and LIKE except when we create a sepcial type of index for LIKE indexing (text_pattern_ops). However, I am wondering if we should create a character lookup during initdb that has the characters ordered so we can do: col LIKE 'ha%' AND col = ha and col = hb Could we do this easily for single-character encodings? We could have: A 1 B 2 C 3 and a non-C locale could be: A 1 A` 2 B 3 We can't handle multi-byte encodings because the number of combinations is too large or not known. Also, we mention you should use the C locale to use normal indexes for LIKE but isn't it more correct to say the encoding has to be SQL_ASCII? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Non-C locale and LIKE
However, I am wondering if we should create a character lookup during initdb that has the characters ordered so we can do: col LIKE 'ha%' AND col = ha and col = hb Could we do this easily for single-character encodings? We could have: A 1 B 2 C 3 and a non-C locale could be: A 1 A` 2 B 3 We can't handle multi-byte encodings because the number of combinations is too large or not known. Also, we mention you should use the C locale to use normal indexes for LIKE but isn't it more correct to say the encoding has to be SQL_ASCII? Would it not be better to take this as an opportunity to integrate ICU ? That would work with both single and multibyte encodings. ... John ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
