Re: [HACKERS] Creating locales.
Tim Uckun wrote: I have been searching without luck on a howto on how to create locales for postgres. Could somebody please point me in the general direction? Thanks. PostgreSQL uses system locales (even to the extent that I was unable to get it use any other locale by setting LC_* variables in /etc/init.d/rc.d/postgres) I did have to modify my locale (et_EE) to _not_ group \xff (yumlaut;) with other y-s but to sort it after all other "standard" chars to work properly with LIKE optimisations. Perhaps the right approach would be to leave \xff alone and to choose some character in the 128-159 range for bigger-than-any-other-char but as \xff is not used in estonian i was able to do away with just moving it. OTOH, it may be a good idea to start a repository for locales that are specifilally modified to work well with postgres. We may want to move the locale stuff inside the backend someday as mandated by SQL standards and then some work would be already done. Hannu
[HACKERS] oid failures on Alpha solved
Hi, It turns out the problem causing the oid failures is with our snprintf. specifically we are formatting "%u" incorrectly: using a enhanced-for-testing version of our snprintf I get. formatting '-1040' with '%lu' snprintf = 18446744073709550576 sprintf = 18446744073709550576 formatting '-1040' with '%u' snprintf = 18446744073709550576 sprintf = 4294966256 oidout() is where the offending call originates, FWIW. snprintf(result, 12, "%u", o); I've massaged in the snprintf.c code from openssh into postgres, and oid now passes the regression test, but have a couple of questions: 1) could the openssh code be a candidate to replace our version? It looks quite a bit more 'featureful', and I'd imagine it is about as safe as snprintf gets. 2) do we _need_ oidout() to "%u", or could we "%lu" and fully take advantage of the longer long on 64bit platforms? cheers. brent
[HACKERS] Re: [DOCS] Inheritance docs error.
Peter Eisentraut [EMAIL PROTECTED] writes: They are all correct: UNDER is the new SQL99 syntax, INHERITS is the traditional Postgres syntax. Current docs do appear to be erroneous: they claim the UNDER phrase goes where INHERIT does, which is not what the grammar thinks. I haven't looked at SQL99 to see which is right. The grammar appears to be correct to the extent that SQL99 wants the UNDER before the column list, so I corrected the documentation at that point. However, the syntax as a whole is not SQL99-compliant. Hmm. After looking at the SQL99 syntax, it seems that what we've done with our grammar is to take the old INHERITS functionality and plaster a vaguely-SQL-like syntax on it. I have to wonder whether this is a good idea. I think it'll get in the way when and if we want to offer true SQL99 UNDER behavior, which is only marginally related to INHERITS. (In particular, SQL99 seems to want an explicit specification of the structured type that's being inherited.) I am strongly inclined to rip out the pseudo-UNDER clause and support only the old-style INHERITS syntax for 7.1. UNDER is adding no functionality and I think we will eventually regret using an SQL keyword for non-SQL semantics. Comments? regards, tom lane
[HACKERS] Re: oid failures on Alpha solved
On 30 Dec 2000 at 14:24 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | formatting '-1040' with '%u' | snprintf = 18446744073709550576 | sprintf = 4294966256 | | oidout() is where the offending call originates, FWIW. | snprintf(result, 12, "%u", o); | | Hm. This is clearly a bug in snprintf. | | OK, I was able to duplicate this failure on Debian Alpha after forcing | our snprintf emulation to be used instead of the system's. Problem is | sloppy signed-vs-unsigned casting in snprintf.c. I've committed a fix. | Another day, another bug... indeed. the most recent snprintf.c works as expected. thank you. brent
Re: [HACKERS] GNU readline and BSD license
On Sat, 30 Dec 2000, Peter Bierman wrote: At 7:15 PM -0500 12/29/00, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Rasmus Lerdorf warned one of you guys that simply linking to GNU readline can contaminate code with the GPL. Readline isn't LGPL which permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. I do not believe that. In fact, I'll go further and say "Horsepucky!" The GPL applies to works that "contain or are derived from" a GPL'd program. Linking to a separately distributed library does not cause psql either to contain or to be derived from libreadline. Some very highly paid lawyers disagree with you. That doesn't make them right, but keep in mind that no one has defined "derivitive work" in a court of law. And RMS isn't a lawyer. I agree readline doesn't taint PG, but IMHO, the more distance between the GPL and PG, the better. OK. For the last time, here's the story about linking, as agreed upon by almost damn everyone: a) dynamic linking is kosher, as of GPL2 b) static linking is OK, but you may NOT redistribute resulting libraries. I hope the above will put the discussion about readline to an end, as Postgres does not distribute statically linked binaries. -alex
[HACKERS] heap_modifytuple() - help needed
Can anybodt give me a few examples on how to use heap_modifytuple() efficiently when I do NOT want to modify an attribute through a postgres function? All the examples given in the source seem to use some return of a postgres function (like current user etc). I just want to insert strings into a tuple cought in a trigger function. I tried to find some useful information regarding the "Datum" type, but I failed to understand how to use it here for my purposes. Any help appreciated - in exchange I volunteer to write proper documentation for heap_modifytuple() once I understood how to work it properly. Regards Horst
RE: [HACKERS] vacuum crash on 6.5.3
Just a supplement. Essentially this isn't a crash bug. This had been a disastrous bug that causes data loss silently. (This is known as 'HEAP_MOVED_IN was not expected' bug but the result could be more serious than I've recognized.) Please apply the patch if you still have pre-7.0 pg db-s and you don't love data loss. Regards. Hiroshi Inoue -Original Message- From: Tatsuo Ishii Althoug this happens on old 6.5.3, I would like to know if this has been already fixed... Here is the scenario: 1) before vacuum, table A has 8850 tuples. 2) vacuum on table A makes postgres crashed. 3) it crashes at line 1758: Assert(num_moved == checked_moved); I examined variables using gdb. num_moved == 8849, check_moved == 8813, num_tuples == 18. 4) if PostgreSQL is not compiled with assertion, vacuum does not crash. However, after vacuum, the number of tuples descreases from 8850 to 8814!! (I am not sure which number is correct, though) I think this is an important problem since a data loss might happen. Any idea? It turns out that this was caused by vacuum's bug. Thanks to Hiroshi, he has identified the problem. I have checked other version of PostgreSQL, and found that at we have had the bug at least since 6.3.2, and it has been fixed in 7.0. Included are patches for 6.5.3 and a test sript to reproduce the bug. Both of them are made by Hiroshi. -- Tatsuo Ishii
