Re: [HACKERS] Request for supported platforms
Folks. start sending in those plaform reports, OS name and version number please. DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler. Using Compaq C V6.4-216 (dtk) on Digital UNIX V4.0G (Rev. 1530) Compiler Driver V6.4-013 (dtk) cc Driver: make[3]: Entering directory `/usr/local/src/postgresql-7.3b3/src/backend/main' cc -std -O4 -Olimit 2000 -I../../../src/include -I/usr/local/include -c -o main.o main.c cc: Error: main.c, line 83: In this statement, errno is not declared. (undeclared) fprintf(stderr, gettext(%s: setsysinfo failed: %s\n), argv[0], strerror(errno)); --^ make[3]: *** [main.o] Error 1 same with GCC 2.95.1. make[1]: Entering directory `/usr/local/src/postgresql-7.3b3-gcc/src/backend/main' gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -I/usr/local/include -c -o main.o main.c main.c: In function `main': main.c:83: `errno' undeclared (first use in this function) make[1]: *** [main.o] Error 1 So, errno function is undefined. This is quite strange, because that section hasn't been changed in the last few months. It's activated from two different #if: one is #if defined(__alpha) other is #if defined(NOFIXADE) || defined(NOPRINTADE) Maybe is the setting of NOFIXADE or NOPRINTADE to be changed upstream? -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 It is more complicated than you think -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] setuid for defaults, constraints and triggers (Was: What user to [sic] defaults execute as?)
Constraints also run as the user modifying a table instead of the table owner. Again I don't see a good reason to want to execute constraints as the user modifying a table. But I do think there can be reasons to want to execute them as the table owner. To summarize, my suggestion for change is: Execute default expressions and constraints as the owner of the table. Execute triggers as the owner of the trigger. ---(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] setuid for defaults, constraints and triggers (Was:
On Thu, 2002-10-31 at 09:54, Bruno Wolff III wrote: Constraints also run as the user modifying a table instead of the table owner. Again I don't see a good reason to want to execute constraints as the user modifying a table. But I do think there can be reasons to want to execute them as the table owner. To summarize, my suggestion for change is: Execute default expressions and constraints as the owner of the table. Execute triggers as the owner of the trigger. Can't necessarily run them as the table owner, as it may give information to other users with the ability to ALTER that table. However, I can see a good argument to allowing running the constraints as the user who created the constraint. This means would require tracking of constraint ownership. -- Rod Taylor ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] setuid for defaults, constraints and triggers (Was: What user to [sic] defaults execute as?)
On Thu, Oct 31, 2002 at 10:17:26 -0500, Rod Taylor [EMAIL PROTECTED] wrote: Can't necessarily run them as the table owner, as it may give information to other users with the ability to ALTER that table. You have to be the table owner to alter a table. So it should be OK to have the default expressions and check constraints run as the owner. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Test of PG7.3.2b2 on SGI Irix
I've built and run the regression tests on PostgreSQL7.3 beta 2 on SGI Irix and found the following suspicious compiler error message: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] setuid for defaults, constraints and triggers (Was:
On Thu, 2002-10-31 at 10:33, Bruno Wolff III wrote: On Thu, Oct 31, 2002 at 10:17:26 -0500, Rod Taylor [EMAIL PROTECTED] wrote: Can't necessarily run them as the table owner, as it may give information to other users with the ability to ALTER that table. You have to be the table owner to alter a table. So it should be OK to have the default expressions and check constraints run as the owner. Yes, default expressions and check constraints could possibly. However, both revoke complex expressions (no sub-selects, etc) so there is little point. Functions can already suid if you are using them in check constraints for complex lookups. An ASSERTION may be appropriate for suid, as would REFERENCES -- but only when explicitly asked for, and those should run as the constraint owner NOT as the table owner. -- Rod Taylor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2.3 vacuum bug
On Thu, 31 Oct 2002, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Ok, fair enough -- I agree that we should treat the two cases differently. But one thing I think we should do in any case is improve the wording of the error message. Got a suggestion? Change: RelationClearRelation: relation 25172 deleted while still in use to: RelationClearRelation: a relation (id: 25172) was deleted while still in use ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] elog(PANIC) should abort()?
I am thinking it would be useful for debugging if elog(PANIC) were to exit by calling abort() so that a core dump would be produced. Going out via proc_exit(), as it now does, seems like a bad idea in any case, since that will try to do a bunch of cleanup activity that's probably inappropriate after a panic. Comments? 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] Request for supported platforms
Alessio Bragadini [EMAIL PROTECTED] writes: Folks. start sending in those plaform reports, OS name and version number please. DOESN'T WORK on Digital Unix/Tru64 4.0g, with both cc or gcc compiler. Evidently main.c needs #include errno.h added. Please add that and see if you get any further. There might be other files with the same problem? regards, tom lane ---(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] Test of PG7.3.2b2 on SGI Irix
Robert E. Bruccoleri [EMAIL PROTECTED] writes: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. No, the code is correct, although no doubt too clever by half :-( All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] setuid for defaults, constraints and triggers (Was: What user to [sic] defaults execute as?)
On Thu, Oct 31, 2002 at 11:15:31 -0500, Rod Taylor [EMAIL PROTECTED] wrote: Yes, default expressions and check constraints could possibly. However, both revoke complex expressions (no sub-selects, etc) so there is little point. I disagree. They can call functions which can do unexpected things. In particular calling nextval in default expressions is common. I think it is also reasonable that the owner of the table and sequence may not want people resetting the value of a sequence, while still wanting them to be able to use nextval when inserting records. Functions can already suid if you are using them in check constraints for complex lookups. Yes, and this is a good idea that can be used now. However I think it would also be a good idea, if users couldn't get burned by running unexpected functions when modifying tables owned by others. In reality it will be rare when you would have mutually untrusted people having this kind of interaction. An ASSERTION may be appropriate for suid, as would REFERENCES -- but only when explicitly asked for, and those should run as the constraint owner NOT as the table owner. References is already handled using the REFERENCES privilege. I am a bit confused by the constraint ownership. As far as I can tell constraints can only be created by the table owner using create table or alter table. I think that constraints are actually implemented with triggers. I beleive that triggers do have owners. I also think that triggers should be run with the access of the trigger owner. I don't know how hard this would be to do. 7.3 does have setuid type effects for running rules and optionally usuable for functions. So my uninformed guess would be that it isn't too hard. ---(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] PG functions in Java: maybe use gcj?
Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: In either case I am concerned about licensing issues. gcj is not under a BSD style license. Depending on what you need you are either dealing with regular GPL, LGPL, or LGPL with a special java exception. I beleive (without giving it too much thought) that doing either 1 or 2 above would end up linking GPL code into postgres. This can be worked around by requiring the the necessary gcj libraries be installed separately and detected at configure time (like is done elsewhere). But is does (I think) present a problem for commercial products that would like to redistribute postgres with pljava. Good point, but unless you want to build a BSD-license Java implementation, there will never be a pljava that doesn't have different licensing restrictions than PG itself does. gcj is at least more free than either Sun's or IBM's JVM ... It depends on what you mean by more free. An architecture that interacts with an external jvm would let you use any jvm (free ones as well as others). From a licensing standpoint it is generally easy to redistribute a jvm or expect the user to have one installed (most java based products out there today do this). However in the proposal here we are talking about requiring a specific jvm (gcj) and actually linking parts of it into postgres. To the extent that GPL code is linked in the GPL extends to the entire code base. As I said previously there are ways to work around this, but it becomes tricky. Especially when a commercial product wants to bundle postgres and pljava. That resulting bundle is probably entirely under the GPL and then any changes to it are also GPL. So it could be the case that this company would be prevented from submitting improvements they made back to the core product because their improvements are GPLed as a result of pljava. Now having said all that, I have been monitoring the progres of gcj for some time because I think there are very interesting possibilities. And I am all for anyone who wants to look into it further and investigate the possiblities. I just want to raise the licensing issue because it can cause problems and it is better to think about them up front than after the fact. Another challenge here it that the java code is going to want to use the jdbc api when communicating with the database. Yes. I think we'd need a new implementation of jdbc that sits atop SPI (invoked via jni I guess) rather than a FE/BE connection. How well layered is our jdbc code --- would this mean a large rewrite, or just rolling in a new bottom layer? It isn't as well layered as it could be, but it isn't too bad. Overall it shouldn't be too much work, but not a little project either. One area that isn't well layered is the assumption that the raw data from the server is in text format, since that is what the FE/BE protocol provides. So all the conversion functions that convert to/from java datatypes do so in this format. This assumption runs deep into the code. As a first pass it would be easiest to get raw data from SPI convert to text and then convert to java datatypes instead of going directly from the internal SPI format directly to java datatypes. This could be improved upon later. regards, tom lane thanks, --Barry ---(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] 7.2.3 vacuum bug
Found another: ERROR: cannot find attribute 2 of relation pg_temp_12100_0 On Thu, 2002-10-31 at 11:33, scott.marlowe wrote: On Thu, 31 Oct 2002, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Ok, fair enough -- I agree that we should treat the two cases differently. But one thing I think we should do in any case is improve the wording of the error message. Got a suggestion? Change: RelationClearRelation: relation 25172 deleted while still in use to: RelationClearRelation: a relation (id: 25172) was deleted while still in use -- Rod Taylor ---(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] 7.2.3 vacuum bug
Rod Taylor [EMAIL PROTECTED] writes: Found another: ERROR: cannot find attribute 2 of relation pg_temp_12100_0 Can you reproduce that? It could be that this just represents someone's temp table deletion committing while VACUUM is partway through trying to build a relcache entry to open the relation. If so, it is only another manifestation of the should-lock-before-relation-open problem. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Dear Tom, Robert E. Bruccoleri [EMAIL PROTECTED] writes: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. No, the code is correct, although no doubt too clever by half :-( How can it be correct? If the assertion checking is turned off, then saveState.currBucket will not be changed, but if assertion checking is on, it will be set to NULL. The only way that it would make no difference would be if the saveState.currBucket were NULL to begin with, but then, why make the assignment? All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: *** abstime.out Thu Oct 31 13:18:04 2002 --- ../expected/abstime.out Wed Nov 21 13:27:25 2001 *** *** 44,50 | Wed Dec 31 16:00:00 1969 PST | infinity | -infinity !| Sat May 10 22:59:12 1947 PST | invalid (7 rows) --- 44,50 | Wed Dec 31 16:00:00 1969 PST | infinity | -infinity !| Sat May 10 23:59:12 1947 PST | invalid (7 rows) *** *** 56,62 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 22:59:12 1947 PST (5 rows) SELECT '' AS six, ABSTIME_TBL.* --- 56,62 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 23:59:12 1947 PST (5 rows) SELECT '' AS six, ABSTIME_TBL.* *** *** 67,73 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | infinity ! | Sat May 10 22:59:12 1947 PST | invalid (6 rows) --- 67,73 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | infinity ! | Sat May 10 23:59:12 1947 PST | invalid (6 rows) *** *** 89,95 ---+-- | Wed Dec 31 16:00:00 1969 PST | -infinity !| Sat May 10 22:59:12 1947 PST (3 rows) SELECT '' AS four, ABSTIME_TBL.* --- 89,95 ---+-- | Wed Dec 31 16:00:00 1969 PST | -infinity !| Sat May 10 23:59:12 1947 PST (3 rows) SELECT '' AS four, ABSTIME_TBL.* *** *** 99,105 | Sun Jan 14 03:14:21 1973 PST | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 22:59:12 1947 PST (4 rows) SELECT '' AS four, ABSTIME_TBL.* --- 99,105 | Sun Jan 14 03:14:21 1973 PST | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 23:59:12 1947 PST (4 rows) SELECT '' AS four, ABSTIME_TBL.* *** *** 121,127 ORDER BY abstime; four | abstime| year | month | day | hour | minute | second --+--+--+---+-+--++ ! | Sat May 10 22:59:12 1947 PST | 1947 | 5 | 10 | 22 | 59 | 12 | Wed Dec 31 16:00:00 1969 PST | 1969 |12 | 31 | 16 | 0 | 0 | Sun Jan 14 03:14:21 1973 PST | 1973 | 1 | 14 |3 | 14 | 21 | Mon May 01 00:30:30 1995 PDT | 1995 | 5 | 1 |0 | 30 | 30 --- 121,127 ORDER BY abstime; four | abstime| year | month | day | hour | minute | second --+--+--+---+-+--++ ! | Sat May 10 23:59:12 1947 PST | 1947 | 5 | 10 | 23 | 59 | 12 | Wed Dec 31 16:00:00 1969 PST | 1969 |12 | 31 | 16 | 0 | 0 | Sun Jan 14 03:14:21 1973 PST | 1973 | 1 | 14 |3 | 14 | 21 | Mon May 01 00:30:30 1995 PDT | 1995 | 5 | 1 |0 | 30 | 30 *** horology.outThu Oct 31 13:18:19 2002 --- ../expected/horology.outWed Sep 18 17:35:25 2002 *** *** 1741,1750 | Wed Mar 15 13:14:02 2000 PST | @ 34 years| Tue Mar 15 13:14:02 1966 PST | Sun Dec 31 17:32:01 2000 PST | @ 34 years| Sat Dec 31 17:32:01 1966 PST | Mon Jan 01 17:32:01 2001 PST | @ 34 years| Sun Jan 01 17:32:01 1967 PST ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 17:19:20 1967 PST ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 11:00:00 1969 PST ! | Thu Jan 01
Re: [HACKERS] 7.2.3 vacuum bug
On Thu, 2002-10-31 at 13:03, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: Found another: ERROR: cannot find attribute 2 of relation pg_temp_12100_0 Can you reproduce that? It could be that this just represents someone's temp table deletion committing while VACUUM is partway through trying to build a relcache entry to open the relation. If so, it is only another manifestation of the should-lock-before-relation-open problem. Yes, but not easily (very timing dependent), takes a lot of worker processes to throw it. So it's likely a part of the locking issue. -- Rod Taylor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Robert E. Bruccoleri [EMAIL PROTECTED] writes: No, the code is correct, although no doubt too clever by half :-( How can it be correct? If the assertion checking is turned off, then saveState.currBucket will not be changed, but if assertion checking is on, it will be set to NULL. The only way that it would make no difference would be if the saveState.currBucket were NULL to begin with, but then, why make the assignment? If assertion checking is off (and the code is otherwise correct) then there's no need to reset saveState.currBucket to NULL, or so at least I interpret the author's intent. Notice that an == test would be completely redundant with the first part of the Assert, since the local currBucket was just assigned from saveState.currBucket. What is really being accomplished here is equivalent to Assert(currBucket); #ifdef USE_ASSERT_CHECKING saveState.currBucket = NULL; #endif However, it's a tad silly to confuse readers this much in order to save one lousy store instruction, so I'm inclined to change it to Assert(currBucket); saveState.currBucket = NULL; IIRC, you're not the first to look at that code and think it's wrong. All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: It looks like your files match the solaris-1947 variants; would you confirm that? If so, please send a patch with a resultmap addition that matches your platform. There is already an entry horology/.*-irix6=horology-no-DST-before-1970 but it looks like that's not triggering on your system. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] float output precision questions
On Thu, Oct 31, 2002 at 12:58:21 -0500, Tom Lane [EMAIL PROTECTED] wrote: But I think an EXTRA_DIGITS setting might be interesting. In particular, suppose we allowed EXTRA_DIGITS to be negative? Setting it to -1 or -2 would go a long way towards eliminating our problems with platform variations in the geometry regression test. My attempt to avoid this problem with the earthdistance regression used a cast to numeric to limit the number of digits to the right of the decimal point. If the normal number of digits displayed is different between two systems, than displaying a fixed number less digits is still going to result in differences. ---(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
[HACKERS] Hi
Hi guys, Just got back from my European vacation - 7.3 still not out? :) Chris ---(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] 7.3b3 passes on MacOSX 10.2.1
I said: Peter Bierman [EMAIL PROTECTED] writes: Perhaps the change from gcc2.x to 3.x changed floats a bit? Could be. We had previous reports of the same diff on OSX 10.2 with a G4 processor, so I was wondering if it was hardware or software differences (geometry-powerpc-darwin.out matches exactly on my G3 laptop running OSX 10.1). I have a 10.2 CD and am planning to update sometime soon to verify this by experiment. I have done the update and now I get the ...40473 output on the same hardware that useta pass. So it's clearly a software-version issue. Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm inclined to think not, and am leaning towards updating the expected file. Comments? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Interesting VACUUM notice
I found a message I've never seen before in VACUUM, its: NOTICE: Too old parent tuple found - can't continue repair_frag The version is Postgresql 7.2.1. The problem occurs in vacuum.c, around line 1700, but the interesting part is the comment around: /* * Read above about cases when * !ItemIdIsUsed(Citemid) (child item is * removed)... Due to the fact that at the moment * we don't remove unuseful part of update-chain, * it's possible to get too old parent row here. * Like as in the case which caused this problem, * we stop shrinking here. I could try to find * real parent row but want not to do it because * of real solution will be implemented anyway, * latter, and we are too close to 6.5 release. - * vadim 06/11/99 */ This sounds like a solution should be available, but it seems to happen anyway. Yesterday I've found no way to fix this problem, but today it's not reproduceable any more. Might this notice indicate a serious problem? Best regards, Mario Weilguni ---(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] float output precision questions
Just one more note, Maybe it makes sense that in the proposal below the parameter EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value of 15 and maximum 18. Its more 'documentable' and maybe easy to understand in general. Pedro M. Ferreira wrote: Yes. I think there are several options. I checked the sprintf(ascii, %A, num) output format and all the numbers that would fail because of DBL_DIG=15 are ok. After insertion on a table and conversion to double after a query, comparison a==b holds. AFAICT %A is system independent. I would (if I may) propose the following: Have two parameters, say DOUBLE_OUTPUT and EXTRA_DIGITS. DOUBLE_OUTPUT would select from decimal output or normalized output. EXTRA_DIGITS would add the required extra digits, from 0 (default) to 3, when output is decimal. EXTRA_DIGITS: in the range [0:3]. 0 as defualt. DOUBLE_OUTPUT: 'DECIMAL': sprintf(ascii, %.*g, DBL_DIG+EXTRA_DIGITS, num); (default) 'NORMALIZED': sprintf(ascii, %A, num); The same could be done for floats (float4). This way PG does not assume anything (DOUBLE_OUTPUT as 'NORMALIZED'), it does not hardwire 'inappropriate' assumptions about the number of significant digits in a double (default EXTRA_DIGITS=0), and it gives flexibility (EXTRA_DIGITS!=0) if needed. I think this is functional and reasonable. Regards, Pedro M. Ferreira regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- -- Pedro Miguel Frazao Fernandes Ferreira Universidade do Algarve Faculdade de Ciencias e Tecnologia Campus de Gambelas 8000-117 Faro Portugal Tel./Fax: (+351) 289 800950 / 289 819403 http://w3.ualg.pt/~pfrazao ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] float output precision questions
Maybe it makes sense that in the proposal below the parameter EXTRA_DIGITS could be SIGNIFICANT_DIGITS with a default value of 15 and maximum 18. Its more 'documentable' and maybe easy to understand in general. Yes agree (or double_significant_digits or format_double_digits ?), but default to DBL_DIG and allow range between 1 and DBL_DIG + 3. format_* could be used for all future output format tweaks. Unfortunately %A is not portable :-( Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] float output precision questions
Zeugswetter Andreas SB SD wrote: Yes agree (or double_significant_digits or format_double_digits ?), but default to DBL_DIG and allow range between 1 and DBL_DIG + 3. format_* could be used for all future output format tweaks. Unfortunately %A is not portable :-( What do you mean ? It is C99, introduced in glibc 2.1. What are the requirements for PostgreSQL ? Pedro ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] float output precision questions
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 30 Oct 2002, Tom Lane wrote: sprintf(ascii, %.*g, DBL_DIG+1, num); and similarly for float4. Given carefully written float I/O routines, reading the latter output should reproduce the originally stored value. Well, on my system, it doesn't look like doing the above sprintfs will actually work for all numbers. I did a simple program using an arbitrary big number and the DBL_DIG+1 output when stuck into another double actually was a different double value. DBL_DIG+2 worked on my system, but... Oh, you're right; I had forgotten about the effects of scale. DBL_DIG=15 means that the system claims to distinguish all 15-digit values, but in a binary system there's more headroom at the bottom end of a decimal order of magnitude. For example, 15-digit values are fine: regression=# select 101::float8 - 100::float8; ?column? -- 1 (1 row) regression=# select 999::float8 - 998::float8; ?column? -- 1 (1 row) but the 9-etc values are over three binary orders of magnitude larger than the 1-etc values, and so they have three less spare bits at the right end. The system would be lying to claim DBL_DIG=16: regression=# select ::float8 - 9998::float8; ?column? -- 2 (1 row) even though values a little over 1e15 are represented perfectly accurately: regression=# select 1001::float8 - 1000::float8; ?column? -- 1 (1 row) If you experiment with 17-digit values, you find that the representable values are about 2 counts apart near 1e16: regression=# select 10001::float8 - 1::float8; ?column? -- 0 (1 row) regression=# select 10002::float8 - 1::float8; ?column? -- 2 (1 row) but they're about 16 counts apart near 9e16: regression=# select 2::float8 - 0::float8; ?column? -- 16 (1 row) regression=# select 1::float8 - 0::float8; ?column? -- 0 (1 row) which is exactly what you'd expect seeing that the values are about a factor of 8 apart. Bottom line: if DBL_DIG=15 and the float arithmetic is binary, then there are some double values that require 17 displayed digits to distinguish, even though not all 16-digit numbers are distinct. So I retract my original proposal and instead suggest that we offer a switch to display either DBL_DIG or DBL_DIG+2 significant digits (and correspondingly increase the digits for float4). The DBL_DIG+2 case should handle the need for exact dump/reload. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] float output precision questions
Pedro M. Ferreira [EMAIL PROTECTED] writes: Zeugswetter Andreas SB SD wrote: Unfortunately %A is not portable :-( What do you mean ? Just what he said. It is C99, introduced in glibc 2.1. What are the requirements for PostgreSQL ? glibc does not define the universe; nor are all platforms supporting C99 yet. regards, tom lane ---(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] float output precision questions
Pedro M. Ferreira [EMAIL PROTECTED] writes: Its like I said before, the guys from matlab (in x86 IEEE float) go to DBL_BIG+3 to have 'maximum precision'. Apparently they have not read the canonical papers in the field. [ googles for a moment... ] See How to read floating point numbers accurately William D. Clinger How to print floating-point numbers accurately Guy L. Steele, Jr., Jon L. White both published at the 1990 ACM Conference on Programming Language Design and Implementation and subsequently reprinted in ACM SIGPLAN Notices Volume 25, Issue 6 (June 1990). I was misremembering these papers to claim DBL_DIG+1 is enough, but actually they prove that DBL_DIG+2 is necessary and sufficient (and give code to do it correctly, too). Printing DBL_DIG+3 is just producing an extra garbage digit; it won't help matters. Any reasonably well-written C library is going to be able to reproduce a double value with DBL_DIG+2 digits of I/O; and if it's not well-written, I would have no confidence in its ability to do so with DBL_DIG+3 digits... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] float output precision questions
Tom Lane wrote: I was misremembering these papers to claim DBL_DIG+1 is enough, but actually they prove that DBL_DIG+2 is necessary and sufficient (and give code to do it correctly, too). Yeahh! If there's a proof its safe to implement. I also Googled a bit and found another paper saying that 17 is the minimum number of significant digits guaranteed to distinguish among IEEE double-precision floating point numbers: Robert G. Burger and R. Kent Dybvig. Printing floating-point numbers quickly and accurately. In Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation, pages 108--116 http://citeseer.nj.nec.com/28233.html Printing DBL_DIG+3 is just producing an extra garbage digit; it won't help matters. Any reasonably well-written C library is going to be able to reproduce a double value with DBL_DIG+2 digits of I/O; and if it's not well-written, I would have no confidence in its ability to do so with DBL_DIG+3 digits... Off course. This is also good in terms of dump storage for big float8 databases. Its one byte less for every float8. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- -- Pedro Miguel Frazao Fernandes Ferreira Universidade do Algarve Faculdade de Ciencias e Tecnologia Campus de Gambelas 8000-117 Faro Portugal Tel./Fax: (+351) 289 800950 / 289 819403 http://w3.ualg.pt/~pfrazao ---(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] float output precision questions
Pedro M. Ferreira [EMAIL PROTECTED] writes: Have two parameters, say DOUBLE_OUTPUT and EXTRA_DIGITS. DOUBLE_OUTPUT would select from decimal output or normalized output. EXTRA_DIGITS would add the required extra digits, from 0 (default) to 3, when output is decimal. I'm not happy with adding the hex-output option, since it's not very portable and doesn't seem necessary to solve the problem anyway. But I think an EXTRA_DIGITS setting might be interesting. In particular, suppose we allowed EXTRA_DIGITS to be negative? Setting it to -1 or -2 would go a long way towards eliminating our problems with platform variations in the geometry regression test. Perhaps something like extra_float_digits int range -2 to 2, default 0 extra_float_digits adjusts the number of digits displayed for float4 and float8 output; the base value of 0 means we output FLT_DIG or DBL_DIG digits respectively. Per discussion, there's no reason to allow a value greater than 2, but I'm not as sure what the lower limit should be --- maybe there's some use in setting it less than -2? 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] float output precision questions
Tom Lane wrote: Bottom line: if DBL_DIG=15 and the float arithmetic is binary, then there are some double values that require 17 displayed digits to distinguish, even though not all 16-digit numbers are distinct. So I retract my original proposal and instead suggest that we offer a switch to display either DBL_DIG or DBL_DIG+2 significant digits (and correspondingly increase the digits for float4). The DBL_DIG+2 case should handle the need for exact dump/reload. Nice. This will be good for number storage purposes. Shall it be done with two parameters, 'DOUBLE_FORMAT' and 'SINGLE_FORMAT', with options 'SHORT' and 'LONG' controlling how the sprintf's are done ? Will someone from pg-people do it or shall I do it for you ? As I said previously, I have seen the GUC stuff and it seem's ok for me to do it. I really do not know if there are any restrictions on who implements what respecting PostgreSQL. Tomorrow we have an holyday in Portugal and I shall leave for the whole week-end, but I can do it on monday. Best regards, Pedro M. Ferreira regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- -- Pedro Miguel Frazao Fernandes Ferreira Universidade do Algarve Faculdade de Ciencias e Tecnologia Campus de Gambelas 8000-117 Faro Portugal Tel./Fax: (+351) 289 800950 / 289 819403 http://w3.ualg.pt/~pfrazao ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] float output precision questions
I sent an email before receiving the one below. I am happier also with the extra_digits way (from the previous email I thought the options were DBL_DIG or DBL_DIG+2). I'm not happy with adding the hex-output option, since it's not very portable and doesn't seem necessary to solve the problem anyway. Agree. Perhaps something like extra_float_digits int range -2 to 2, default 0 extra_float_digits adjusts the number of digits displayed for float4 and float8 output; the base value of 0 means we output FLT_DIG or DBL_DIG digits respectively. Agree. Per discussion, there's no reason to allow a value greater than 2, but I'm not as sure what the lower limit should be --- maybe there's some use in setting it less than -2? I could see some use. At least in my type of application. When people are shure they only need p significant digits, they can set extra_float_digits to an apropriate negative value and spare a lot in storage for dumps and backups. In this case it would make sense to let extra_float_digits go to -13. Regards, Pedro 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 -- -- Pedro Miguel Frazao Fernandes Ferreira Universidade do Algarve Faculdade de Ciencias e Tecnologia Campus de Gambelas 8000-117 Faro Portugal Tel./Fax: (+351) 289 800950 / 289 819403 http://w3.ualg.pt/~pfrazao ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] integer array, push and pop
What version of postgres are you using? I am using PostgreSQL 7.3b1 on
i686-pc-linux-gnu, compiled by GCC 2.96 and when I execute the following
statement:
select '{124,567,66}'::int[] + 345;
I get the error:
ERROR: cache lookup failed for type 0
Any ideas?
Thanks for your help!
-r
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump and large files - is this a problem?
Peter Eisentraut [EMAIL PROTECTED] writes: The proposed fix was to include the flex output in some other file (such as the corresponding grammar file) rather than to compile it separately. Seems like a reasonable solution. Can you make that happen in the next day or two? If not, I'll take a whack at it ... regards, tom lane ---(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] Hi
Christopher Kings-Lynne wrote: Hi guys, Just got back from my European vacation - 7.3 still not out? :) Nope, we think maybe RC1 tomorrow. I was busy the past two days and am catching up on email just now. -- 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
Re: [HACKERS] Request for supported platforms
Seems like someone ought to issue a call for port reports. The supported platforms list hasn't been touched ... Good point. Thomas, can you take that on? No, at least not now. I'm not able to communicate reliably with the mailing lists, and so can not coordinate anything :( Not sure when or if that will be resolved, but I'll be out of town next week so... [ Reposted with proper subject line.] OK, Tom will be away next week, and Thomas will too. I can do it. Folks. start sending in those plaform reports, OS name and version number please. The current platform list is: http://developer.postgresql.org/docs/postgres/supported-platforms.html $ uname -a FreeBSD avienda.nxad.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Oct 28 18:20:14 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DELLAPTOP i386 $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) Looks like the only problem on beta3 is that the geometry bits are failing, but I'm not 100% if they haven't already been solved. -sc *** ./expected/geometry-positive-zeros-bsd.out Tue Sep 12 14:07:16 2000 --- ./results/geometry.out Thu Oct 31 23:53:31 2002 *** *** 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) *** *** 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (0,0),(-20,-20) ! | (0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) --- 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (-0,0),(-20,-20) ! | (-0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,-0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) *** *** 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) --- 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,-0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,-0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) *** *** 266,272 | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! | (0,0.0828402366863905),(-0.201183431952663,0) | (-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953) | (-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201) | (-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586) --- 266,272 | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! |
