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 usef
[ 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 bo
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 in
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 lik
> -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: pgsql-hac
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 input
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
> -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 semantic
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 database_size(n
"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 ca
> -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
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 br
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
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 n
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 folk
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 t
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
> nutshel
> -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
>
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 nam
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 o
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 datab
> -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
> re
> -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,
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_rela
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. Getti
> -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
> > > e
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 I
> -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(), relat
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
Bruce Momjian 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 would have
been a bug
Tom Lane wrote:
> Bruce Momjian 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
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 returns
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
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:
> >
> >
> >>Chr
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
Bruce Momjian 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 of trouble before we
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: DataBase
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 broadcast)
50 matches
Mail list logo
