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
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
[ 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,
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
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
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
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
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)?
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
-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:
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:
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)?
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
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
-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
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
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
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
-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
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
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
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
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
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
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?
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
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
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
-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.
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
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
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
-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
-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
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
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.
-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?
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
-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(),
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
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
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
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
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
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
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:
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
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
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:
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
50 matches
Mail list logo