Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Mark Cave-Ayland
Hi Tom, What needs more discussion is that it seems to me to make sense to extend the standard opclasses to handle the four Y-direction operators comparable to the X-direction operators that are already there, that is above, below, overabove, and overbelow. As part of PostGIS

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Bruce Momjian
Dave Page wrote: The reason it happen that way was because we already had the code as a contrib-style module for pgAdmin. It was posted because we recognised that it was becoming a PITA for pgAdmin users to compile a new server-side component and the functions seemed like they would be useful

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions)

2005-06-24 Thread Tom Lane
[ moving to -hackers for a wider audience ] Today's issue: should the GREATEST/LEAST functions be strict (return null if any input is null) or not (return null only if all inputs are null, else return the largest/smallest of the non-null inputs)? Pavel Stehule [EMAIL PROTECTED] writes: On Thu,

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Tom Lane
Mark Cave-Ayland [EMAIL PROTECTED] writes: The operators I went for were as follows: A | B - true if A's bounding box overlaps or is below B's bounding box A | B - true if B's bounding box overlaps or is above B's bounding box A | B - true if A's bounding box is strictly

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread William White
Tom Lane wrote: However, given that the behavior has been broken since the rtree code was written and nobody noticed except bwhite, I think it's pretty low-priority to back-patch. Well, leave it to me to find the obscure bugs in other people's code, and miss the blatant ones in my own. It's

Re: [HACKERS] [PATCHES] O_DIRECT for WAL writes

2005-06-24 Thread Tom Lane
ITAGAKI Takahiro [EMAIL PROTECTED] writes: ... So I'll post the new results: checkpoint_ | writeback | segments| cache | open_sync | fsync=false | O_DIRECT only | fsync_direct | open_direct

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle

2005-06-24 Thread Andrew Dunstan
Tom Lane wrote: [ moving to -hackers for a wider audience ] Today's issue: should the GREATEST/LEAST functions be strict (return null if any input is null) or not (return null only if all inputs are null, else return the largest/smallest of the non-null inputs)? My initial reaction was

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions)

2005-06-24 Thread Mike Rylander
On 6/24/05, Tom Lane [EMAIL PROTECTED] wrote: [ moving to -hackers for a wider audience ] Today's issue: should the GREATEST/LEAST functions be strict (return null if any input is null) or not (return null only if all inputs are null, else return the largest/smallest of the non-null inputs)?

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Andreas Pflug
Bruce Momjian wrote: Dave Page wrote: The reason it happen that way was because we already had the code as a contrib-style module for pgAdmin. It was posted because we recognised that it was becoming a PITA for pgAdmin users to compile a new server-side component and the functions seemed

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 14:00 To: Dave Page Cc: PostgreSQL-development; Andreas Pflug Subject: Re: Server instrumentation patch Well, I see Marc replying that dbsize should be moved completely from contrib:

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions)

2005-06-24 Thread John Hansen
I'd vote that these functions should follow the semantics of the , and operators. (NULL x) is NULL; ... John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Friday, June 24, 2005 11:21 PM To: Pavel Stehule Cc:

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE

2005-06-24 Thread Robert Treat
On Fri, 2005-06-24 at 09:21, Tom Lane wrote: [ moving to -hackers for a wider audience ] Today's issue: should the GREATEST/LEAST functions be strict (return null if any input is null) or not (return null only if all inputs are null, else return the largest/smallest of the non-null inputs)?

Re: [HACKERS] [PATCHES] O_DIRECT for WAL writes

2005-06-24 Thread Jim C. Nasby
On Fri, Jun 24, 2005 at 09:37:23AM -0400, Tom Lane wrote: ITAGAKI Takahiro [EMAIL PROTECTED] writes: ... So I'll post the new results: checkpoint_ | writeback | segments| cache | open_sync | fsync=false | O_DIRECT only | fsync_direct | open_direct

Re: [HACKERS] HaveNFreeProcs ?

2005-06-24 Thread Jim C. Nasby
On Thu, Jun 23, 2005 at 12:44:25AM -0400, Tom Lane wrote: I wrote: ... because it's written to not loop more than superuser_reserved_connections times, and it's hard to imagine anyone would set that to more than half a dozen or so. We could help keep people on the correct path if guc.c

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Mark Cave-Ayland
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 14:27 To: Mark Cave-Ayland (External) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; oleg@sai.msu.su; pgsql-hackers@postgresql.org; 'PostGIS Development Discussion' Subject: Re: Fixing r-tree semantics

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Michael Paesold
Andreas Pflug wrote: For the second, please supply a patch that moves _all_ of dbsize into the main server. I think we have agreement on that. I don't think so. As I mentioned, those views are broken. Do you want them to be in core anyway? Why is e.g. this one broken: int8

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions)

2005-06-24 Thread Tom Lane
John Hansen [EMAIL PROTECTED] writes: I'd vote that these functions should follow the semantics of the , and operators. (NULL x) is NULL; Well, that's a fair analogy, but then so is the analogy to MAX/MIN ... so it seems about a wash to me. regards, tom lane

Re: [HACKERS] creating WITH HOLD cursors using SPI

2005-06-24 Thread Andrew Dunstan
Abhijit Menon-Sen wrote: Hi. I've been working on making it possible for PL/Perl users to fetch large result sets one row at a time (the current spi_exec_query interface just returns a big hash). The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have an spi_fetchrow that

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Dave Page
-Original Message- From: Michael Paesold [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 16:48 To: Andreas Pflug Cc: Dave Page; PostgreSQL-development Subject: Re: [HACKERS] Server instrumentation patch Andreas Pflug wrote: For the second, please supply a patch that moves

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Andreas Pflug
Michael Paesold wrote: Andreas Pflug wrote: For the second, please supply a patch that moves _all_ of dbsize into the main server. I think we have agreement on that. I don't think so. As I mentioned, those views are broken. Do you want them to be in core anyway? Why is e.g. this one

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Jim C. Nasby
On Fri, Jun 24, 2005 at 05:10:15PM +0100, Dave Page wrote: You have pg_database_size(oid) and database_size(name). Afaict, the latter is equivalent to: SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname = 'foo')) My main concern is that the names are inconsistent for no

Re: [HACKERS] [PATCHES] Function's LEAST, GREATEST and DECODE (Oracle vararg polymorphic functions)

2005-06-24 Thread David Fetter
On Fri, Jun 24, 2005 at 09:21:25AM -0400, Tom Lane wrote: [ moving to -hackers for a wider audience ] Today's issue: should the GREATEST/LEAST functions be strict (return null if any input is null) or not (return null only if all inputs are null, else return the largest/smallest of the

Re: [HACKERS] [PATCHES] O_DIRECT for WAL writes

2005-06-24 Thread Josh Berkus
Jim, Josh, is this something that could be done in the performance lab? That's the idea. Sadly, OSDL's hardware has been having critical failures of late (I'm still trying to get test results on the checkpointing thing) and the GreenPlum machines aren't up yet. I need to contact those

Re: [GENERAL] [HACKERS] [PATCHES] Removing Kerberos 4

2005-06-24 Thread Jim C. Nasby
On Thu, Jun 23, 2005 at 07:34:30PM +0200, Magnus Hagander wrote: Has Kerb4 been marked as depricated in the docs at all? If not it might be best to just do that and then yank it later. Yes, since 7.4. http://www.postgresql.org/docs/8.0/static/auth-methods.html#KERBEROS-AUT H

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Michael Paesold
Andreas Pflug wrote: Michael Paesold wrote: Andreas Pflug wrote: For the second, please supply a patch that moves _all_ of dbsize into the main server. I think we have agreement on that. I don't think so. As I mentioned, those views are broken. Do you want them to be in core anyway?

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Michael Paesold
Dave Page wrote: You have pg_database_size(oid) and database_size(name). Afaict, the latter is equivalent to: SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname = 'foo')) The typing is even more e.g. for tables or indexes, though. Of course you can use the raw form, but why

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Bruce Momjian
Dave Page wrote: I vote for all (possibly corrected) functions to be moved into core. You have pg_database_size(oid) and database_size(name). Afaict, the latter is equivalent to: SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname = 'foo')) My main concern is that the

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Bruce Momjian
Dave Page wrote: The current version of the patch only moves those functions he wants. Marc says he wants them all moved, and I agree. OK - did you see Andreas' response to why he hadn't done that (it was actually posted in response to your original query, not Marcs)? In a nutshell, the

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Dave Page
-Original Message- From: Michael Paesold [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 17:53 To: Dave Page; Andreas Pflug Cc: PostgreSQL-development Subject: Re: [HACKERS] Server instrumentation patch My main concern is that the names are inconsistent for no obvious reason.

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Bruce Momjian
Dave Page wrote: -Original Message- From: Michael Paesold [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 17:53 To: Dave Page; Andreas Pflug Cc: PostgreSQL-development Subject: Re: [HACKERS] Server instrumentation patch My main concern is that the names are

[HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
The following functions are currently in contrib/dbsize. As Bruce has suggested, we should discuss which functions should or shouldn't be moved into the backend, and which should be renamed. int8 pg_database_size(oid) int8 database_size(name) Both return the database size in bytes, the first by

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Bruce Momjian
Dave Page wrote: The following functions are currently in contrib/dbsize. As Bruce has suggested, we should discuss which functions should or shouldn't be moved into the backend, and which should be renamed. int8 pg_database_size(oid) int8 database_size(name) Both return the database

Re: [HACKERS] Server instrumentation patch

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 18:47 To: Dave Page Cc: PostgreSQL-development; Andreas Pflug Subject: Re: [HACKERS] Server instrumentation patch The security issue is that we didn't want the backend to be able to read/write

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 20:45 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration My personal view is that pg_database_size, pg_relation_size and pg_tablespace_size, as well

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Bruce Momjian
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 20:45 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration My personal view is that pg_database_size, pg_relation_size and

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Andrew Dunstan
Bruce Momjian wrote: So drop total_relation_size(), relation_size_components(), and what else? But these answer easily the question I see most asked - how much space in total does the relation occupy. I'd like to see at least one of these, properly named and fixed w.r.t. schemas.

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:07 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration So drop total_relation_size(), relation_size_components(), and what else?

Re: [HACKERS] PL/pgSQL Debugger Support

2005-06-24 Thread Bob
My understanding is that EMS Hitech is just doing client side debugging. That is they are taking your function and creating a new process to follow the flow of the program. So if they mess up something you may thing your program is doing one thing when it is really doing something else. Maybe

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:12 To: Bruce Momjian Cc: Dave Page; PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration Bruce Momjian wrote: So drop total_relation_size(),

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Bruce Momjian
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Assuming we don't get such a case, and a chance to fix it, before 8.1 (while still hoping we will get it fixed properly, we can't be sure, can we? If we were, it'd be fixed already). In this case, will you consider such a kludgy

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: I have been running some tests to try to see the lock table corruption but I have been unable to reproduce the problem. It's possible that what Rod was complaining of is fixed in CVS tip --- see discussion about RemoveFromWaitQueue() bug. If so, it

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I have been running some tests to try to see the lock table corruption but I have been unable to reproduce the problem. It's possible that what Rod was complaining of is fixed in CVS tip --- see discussion about

Re: [HACKERS] [COMMITTERS] pgsql: Fix NUMERIC modulus to properly truncate

2005-06-24 Thread Bruce Momjian
With no conclusion on this, I have added a TODO item: * Add NUMERIC division operator that doesn't round? Currently NUMERIC _rounds_ the result to the specified precision. This means division can return a result that multiplied by the divisor is greater than the dividend, e.g. this

Re: [HACKERS] [SQL] ARRAY() returning NULL instead of ARRAY[]

2005-06-24 Thread Bruce Momjian
Is this a TODO item? --- Markus Bertheau ? wrote: ? ???, 06/06/2005 ? 08:58 -0700, Joe Conway ?: Joe Conway wrote: Actually, consistent with my last post, I think array_upper() on a zero-element array should

Re: [HACKERS] [COMMITTERS] pgsql: Fix NUMERIC modulus to properly

2005-06-24 Thread Bruce Momjian
I don't think we can justify having NUMERIC division default to truncation, especially since most division has non-zero decimal digits. --- Paul Tillotson wrote: Bruce Momjian wrote: Tom Lane wrote: Christopher

Re: [HACKERS] [BUGS] BUG #1467: fe_connect doesn't handle EINTR right

2005-06-24 Thread Bruce Momjian
Though we have had no problem reports of this, there is confirmation that our code is incorrect. Would someone develop a patch to fix this? Thanks. --- Florian Hars wrote: The following bug has been logged online:

Re: [HACKERS] [PATCHES] regexp_replace

2005-06-24 Thread Bruce Momjian
Atsushi Ogawa wrote: I think that it is good to specify the flags by one character as well as Perl. I propose the following specification: regexp_replace(source text, pattern text, replacement text, [flags text]) returns text The flags can use the following values: g: global (replace

Re: [HACKERS] [BUGS] BUG #1467: fe_connect doesn't handle EINTR right

2005-06-24 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: Though we have had no problem reports of this, there is confirmation that our code is incorrect. Would someone develop a patch to fix this? s/there is confirmation/there is an entirely unsupported assertion/ I'd like to see an actual demonstration

[HACKERS] get_rel_* functions in lsyscache.c

2005-06-24 Thread Jaime Casanova
Hi, i have a doubt... it seems to me that the get_rel_* functions in lsyscache do the same as doing heap_open(); Calling the appropiate macro Relation* heap_close(); is there any difference between them? in wich situation is one better than the other? -- regards, Jaime Casanova (DBA:

[HACKERS] #ifdef NOT_USED

2005-06-24 Thread Jaime Casanova
Hi, i have found several #ifdef NOT_USED marked code... i guess this is dead code... is safe to remove it? there is some reason you just hide it and not remove the code? -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of