Re: [HACKERS] Format of the Money field
At 12:55 02/02/01 -0400, The Hermit Hacker wrote: On Fri, 2 Feb 2001, Peter T Mount wrote: When did the MONEY type change it's output format? While working on the JDBC test suite, Money broke. It seems to output: $10.99 ($10.99) for negative values While since ages past, the PGMoney class interprets it as a number (no currency symbol). Looking over at Thomas and asking him, his recollection is that it always had the currency symbol ... but he's not 100% certain about that ... Can you confirm with the 7.0.3 server? As I just said to Mitch (who tested against 6.4 and it had the currency symbol) no one must use Money via JDBC as no one's found it before. The PGMoney class dates from the 6.2/6.3 days so it might date back that far. I'll fix it anyhow. Peter
[HACKERS] 7.1beta4 works well
It works! Our production controlling system seems to work with 7.1beta4. In addition, I solved the conversion function problem which was described in one of my last mails. The problem was I used malloc() instead of palloc(). Thanks to all of you who developed 7.1 and helped solving the conversion function problem. Regards, Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX
I have tested and works well. . - Original Message - From: "Bruce Momjian" [EMAIL PROTECTED] To: "Maurizio" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 7:21 PM Subject: Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX I have applied the following patch for QNX. I had to do the ECHO test in pgc.l because pgc.c is generated from pgc.l. Can you test this to see it fixes the problem? in [ Charset ISO-8859-1 unsupported, converting... ] I have compiled 7.1 b3 in QNX but to let postgresql works I changed something. In src/backend/port/qnx4/sem.c #define SEMMAX SEMS_PER_SET) --OLD #define SEMMAX (PROC_NSEMS_PER_SET + --NEW in src/include/storage/s_lock.h #if --OLD #if (defined(__i386__) --NEW in src/interfaces/ecpg/preproc/pgc.c #ifndef -OLD #ifndef (ECHO || --NEW Attached are the files Maurizio Cauci DREAMTECH di Cauci Maurizio Via Ronchetti, 2 - 21013 Gallarate (VA) www.dreamtech-it.com [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ? config.log ? config.cache ? config.status ? GNUmakefile ? src/Makefile.custom ? src/GNUmakefile ? src/Makefile.global ? src/log ? src/crtags ? src/backend/port/Makefile ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_restore ? src/bin/pg_dump/pg_dumpall ? src/include/config.h ? src/include/stamp-h ? src/interfaces/libpq/libpq.so.2.1 Index: src/backend/port/qnx4/sem.c === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/qnx4/sem.c,v retrieving revision 1.3 diff -c -r1.3 sem.c *** src/backend/port/qnx4/sem.c 2000/04/12 17:15:30 1.3 --- src/backend/port/qnx4/sem.c 2001/02/02 18:13:12 *** *** 26,32 #define SETMAX ((MAXBACKENDS + PROC_NSEMS_PER_SET - 1) / PROC_NSEMS_PER_SET) ! #define SEMMAX (PROC_NSEMS_PER_SET) #define OPMAX 8 #define MODE 0700 --- 26,32 #define SETMAX ((MAXBACKENDS + PROC_NSEMS_PER_SET - 1) / PROC_NSEMS_PER_SET) ! #define SEMMAX (PROC_NSEMS_PER_SET+1) #define OPMAX 8 #define MODE 0700 Index: src/include/storage/s_lock.h === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/include/storage/s_lock.h,v retrieving revision 1.86 diff -c -r1.86 s_lock.h *** src/include/storage/s_lock.h 2001/01/24 19:43:28 1.86 --- src/include/storage/s_lock.h 2001/02/02 18:13:13 *** *** 112,118 */ ! #if defined(__i386__) #define TAS(lock) tas(lock) static __inline__ int --- 112,118 */ ! #if defined(__i386__) !defined(__QNX__) #define TAS(lock) tas(lock) static __inline__ int Index: src/interfaces/ecpg/preproc/pgc.l === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/ecpg/preproc/pgc.l,v retrieving revision 1.73 diff -c -r1.73 pgc.l *** src/interfaces/ecpg/preproc/pgc.l 2001/01/24 19:43:29 1.73 --- src/interfaces/ecpg/preproc/pgc.l 2001/02/02 18:13:17 *** *** 35,40 --- 35,45 #undef yywrap #endif /* yywrap */ + #ifdef __QNX__ + /* For some reason, QNX needs this, 2001-02-02 */ + #define ECHO (void) fwrite( yytext, yyleng, 1, yyout ) + #endif + #define YY_NO_UNPUT extern YYSTYPE yylval;
Re: [HACKERS] SF company wants to hire pgsql hacker
On Wed, 31 Jan 2001, Bruce Momjian wrote: A San Francisco company wants to hire a PostgreSQL developer to work on improving the database, and to do some work for the company. I am here at LinuxWorld right now with the CIO of the company. The candidate should be based in North America for Visa reasons, and should be willing to relocate to the San Francisco area. Just as an appendum, when talking to the gentlemen at the show, he indicated to me that Canadian's were welcome to apply, as getting a TN1(?) was relatively easy to acquire, just in case some of the Canadian's were automagically thinking the words "Visa reasons" were automatically excluding them as well ...
Re: [HACKERS] configure problem with krb4 and ssl when compiling7.1beta4
Jun Kuwamura writes: (1) KTH-KRB4(Kerberos4) require -lresolve to configure. Exact name of the symbol required? (2) No OpenSSL library path in generated Makefile in src/interfaces/python. -L/usr/local/ssl/lib must be added by hand. Will fix that. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: Format of the Money field
Just a question on this for my own personal satisfaction... What's the standard on Money type (if there is one) and if it doesn't include the $ (of course that would change based on what currency you were using) then is it any different than numeric(9,2)? numeric(9,2) is what I use for all fields that need to hold a dollar amount so I'm curious.. I remember reading in the documentation that money was numeric(9,2) with the dollar sign added but I wanted to check with the man :-) -Mitch - Original Message - From: "Peter Mount" [EMAIL PROTECTED] To: "Mitch Vincent" [EMAIL PROTECTED]; "The Hermit Hacker" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 03, 2001 5:50 AM Subject: Re: Format of the Money field At 12:07 02/02/01 -0500, Mitch Vincent wrote: hhs= select version(); version --- PostgreSQL 6.4.2 on i386-unknown-freebsd3.1, compiled by gcc 2.7.2. [snip] If it changed, it looks like it changed a long time ago! :-) Hmm, shows how many people use Money via JDBC then, as no one's reported it before. I only found out while testing JBuilder's interaction with the JDBC driver. Peter -Mitch - Original Message - From: "The Hermit Hacker" [EMAIL PROTECTED] To: "Peter T Mount" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 11:55 AM Subject: Re: Format of the Money field On Fri, 2 Feb 2001, Peter T Mount wrote: When did the MONEY type change it's output format? While working on the JDBC test suite, Money broke. It seems to output: $10.99 ($10.99) for negative values While since ages past, the PGMoney class interprets it as a number (no currency symbol). Looking over at Thomas and asking him, his recollection is that it always had the currency symbol ... but he's not 100% certain about that ... Can you confirm with the 7.0.3 server?
Re: [HACKERS] TODO list: Allow Java server-side programming
Peter Mount writes: Thats correct. Basically you are talking of something like PL/Java. The Java side would be simple, but its linking the JVM to the backend that's the problem. I've tried that recently, here's how it looks as far as Linux JVMs go: * Kaffe has a very polluted name space. Calls to its own functions get resolved to PostgreSQL, and vice versa. Crash and burn result. The Kaffe folks have admitted that this should be fixed but I didn't look farther yet. * The Sun/Blackdown JVM didn't work at all (not even 'java -version') until I upgraded my libc. Then a simple test run crashes with an "error external to JVM"; at first it looked like a segfault when referencing a string constant. In gdb I saw myself faced with about 10 threads running when nothing was going on yet, at which point I was too exhausted to proceed. * IBM's offering didn't work at all. I don't recall the problem anymore but I think it didn't even link correctly. So currently I don't see how this could become a mainstream project, let alone across platforms. I know some people think this would slow the backend down, but it's only the instanciation of the JVM thats slow, hence the other reason fork() is holding this back. Ideally you would want the JVM to be running with PostMaster, and then each backend can then use the JVM as and when necessary. But how do the other languages cope? Starting up a new Perl for each backend can't be so cheap either. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] TODO list: Allow Java server-side programming
On Sat, 3 Feb 2001, Peter Mount wrote: It's been a while since I delved into the backend, but unless it's changed from fork() to threading, I don't really see this happening, unless someone who knows C that well knows of a portable way of communicating between two processes - other than RMI. If that could be solved, then you could use JNI to interface the JVM. There are many ways one can do this: a) each backend will have a JVM linked in (shared object). This is the way perl/tcl/ruby is embedded, and it works pretty nice. But, Java ['s memory requirement] sucks, therefore, this may not be the optimal way. I know some people think this would slow the backend down, but it's only the instanciation of the JVM thats slow, hence the other reason fork() is holding this back. Ideally you would want the JVM to be running with PostMaster, and then each backend can then use the JVM as and when necessary. b) since JVM is threaded, it may be more efficient to have a dedicated process running JVM, and accepting some sort of IPC connections from postgres processes. The biggest problem here is SPI, there aren't a good way for that JVM to talk back to database. c) temporarily, to have quick working code, you can reach java using hacks using programming languages already built into postgres. Both TCL (tcl blend) and Perl (JPL and another hack which name escapes me) are able to execute java code. SPI is possible, I think both of these bindings are two-way (you can go perl-java-perl-java). Might be worth a quick try? -alex
Re: [HACKERS] Re: Format of the Money field
On Sat, Feb 03, 2001 at 11:39:29AM -0500, Mitch Vincent wrote: What's the standard on Money type (if there is one) and if it doesn't include the $ (of course that would change based on what currency you were using) then is it any different than numeric(9,2)? numeric(9,2) is what I use for all fields that need to hold a dollar amount so I'm curious.. I remember reading in the documentation that money was numeric(9,2) with the dollar sign added but I wanted to check with the man :-) Oh, never heard of currency?? NOT every country is using dollars. In a few months we in Europe are going to use the Euro. A money-type is normaly a floating type with a precision of 5 (float(5)). A money field is just like an float, only less precies. By the way, storing money values with an decimal precision is a (mostly) a bad thing. We Save currency amounts in the smallest unit. We save every amount in Eurocents. Our programs format the amount to the proper format (US-format (35,673.56) or EuropeannFormat (35.673,56). Currency signs are bad things in databases. Most database are international, so most amounts also! Sorry for this hard correction. Dave Mertens System Administrator ISM, Netherlands [EMAIL PROTECTED]
[HACKERS] Re: Re: Format of the Money field
I acknowledged the bad nature of the money field (pretty clearly stated in my email, I think).. I agree, it shouldn't contain a sign of anything.. My applications are used in the US and in the US only so I don't have issue with the currency symbol. I don't use the money type anyway (the example I used was from someone else's code!).. What I was actually asking about was the need for the money type, the same thing can be achieved using the other data types (in fact the documentation lists money as numeric(9,2) with the $ added I believe).. All that for exactly what you said, currency. There are as many currencies as countries (almost) so I totally agree, a symbol is A Bad Thing(TM).. You're also right (and bring up a good point) about the storing of money in the smallest unit if you're coding international... I haven't had to yet but it's something I'll be sure to do if it ever comes up.. Of course all this is moot, Peter already said he was changing it and that it shouldn't have been that way, it's just been overlooked (probably because no one is using the money type)! :-) I apologize to the list, I meant to send that email directly to Peter -- I was too quick on the send.. -Mitch - Original Message - From: "Dave Mertens" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 03, 2001 2:12 PM Subject: Re: Re: Format of the Money field On Sat, Feb 03, 2001 at 11:39:29AM -0500, Mitch Vincent wrote: What's the standard on Money type (if there is one) and if it doesn't include the $ (of course that would change based on what currency you were using) then is it any different than numeric(9,2)? numeric(9,2) is what I use for all fields that need to hold a dollar amount so I'm curious.. I remember reading in the documentation that money was numeric(9,2) with the dollar sign added but I wanted to check with the man :-) Oh, never heard of currency?? NOT every country is using dollars. In a few months we in Europe are going to use the Euro. A money-type is normaly a floating type with a precision of 5 (float(5)). A money field is just like an float, only less precies. By the way, storing money values with an decimal precision is a (mostly) a bad thing. We Save currency amounts in the smallest unit. We save every amount in Eurocents. Our programs format the amount to the proper format (US-format (35,673.56) or EuropeannFormat (35.673,56). Currency signs are bad things in databases. Most database are international, so most amounts also! Sorry for this hard correction. Dave Mertens System Administrator ISM, Netherlands [EMAIL PROTECTED]
Re: [HACKERS] Like vs '=' bug with indexing
m w [EMAIL PROTECTED] writes: Here is the problem: Depending on whether there is an index or not, 'like' behaves differently. Please provide a complete, self-contained example with which we can reproduce the problem. regards, tom lane
Re: [HACKERS] Like vs '=' bug with indexing
--- Tom Lane [EMAIL PROTECTED] wrote: m w [EMAIL PROTECTED] writes: Here is the problem: Depending on whether there is an index or not, 'like' behaves differently. Please provide a complete, self-contained example with which we can reproduce the problem. I am trying to create a test function and some data that reproduces the problem easily, but I think I know what it is. It is a two bug issue. I had a bug in my code in that I added the "\0" to the end of my strings when I converted from a C string to a postgres "text" object. I think this exposes a bug in postgres where either index or table scans (I'm not sure which just yet) treat a zero differently than a non-zero in a varchar. It looks as if some section of code is using the zero to terminate a string and another section of code is not. So at some point data which should be the same differes either on length of data, or the trailing zero compared to an uninitialized byte. Removing the terminating zero from the postgres string fixes the problem, but, if I understand postgres well enough, this should not make a difference, and should be reported as a bug anyway. __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Re: [HACKERS] Like vs '=' bug with indexing
m w [EMAIL PROTECTED] writes: I think this exposes a bug in postgres where either index or table scans (I'm not sure which just yet) treat a zero differently than a non-zero in a varchar. Embedded zeroes aren't supported in char/varchar/text fields, and cannot be supported in a portable fashion, since these datatypes rely on functions like strcoll() that don't allow embedded nulls in strings. It wouldn't surprise me too much if there are inconsistent behaviors between indexscans and seqscans for such invalid data. It doesn't seem real practical for us to examine the output of every C-coded function to make sure it produces a valid value of the datatype. Illegal returned values are a fault of the function, and ensuing misbehaviors are still its fault ... regards, tom lane
