Magnus Hagander schrieb:
It occurs to me that there is no longer any great need to
have a separate hackers list for win32 development. Perhaps
we should close it down now and keep all development on -hackers?
I also think this is a good idea. The number of win32 only issues of
-hacker level
My company has written a 64-bit large object API, extending the postgresql
server to be able to read/write/seek/tell/open/close objects larger than 2GB.
If the hackers community considers this valuable, we will submit the changes
back for the rest of the community to share.
From one of my
On Sat, Sep 17, 2005 at 01:40:28AM -0400, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 17 Sep 2005, Tom Lane wrote:
It'd be real interesting to see comparable numbers from some non-Linux
kernels, particularly commercial systems like Solaris.
Did you see the Solaris
On Fri, 2005-09-16 at 20:48 -0400, Bruce Momjian wrote:
We can go three ways. We can add a boolean GUC to control printing of
the query during a timeout, but that seems like overkill. We can add a
new level for log_min_error_statement that is just above error, but that
seems confusing. I
Hi,
PostgreSQL's grammer allows you to specify the operator to sort with in
the ORDER BY clause. Various bits of the backend support this feature,
yet it appears to partially undocumented. I can't find it in the ORDER
BY [1] section but there is a paragraph on it under the SELECT
documentation
Martjin,
We can continue to support USING [op] as long as [op] is one of the GT
or LT operators in the OPERATOR CLASS. This restriction may exist
already, I can't tell.
All we lose is the ability to say USING [arbitrary op]. Does anybody
use this. Would people object to requiring the
On Sun, Sep 18, 2005 at 12:34:10PM -0700, Josh Berkus wrote:
All we lose is the ability to say USING [arbitrary op]. Does anybody
use this. Would people object to requiring the operator after USING to
be part of an operator class?
Hmmm ... would this prevent the hackish workaround for
Martijn van Oosterhout wrote:
On Sun, Sep 18, 2005 at 12:34:10PM -0700, Josh Berkus wrote:
All we lose is the ability to say USING [arbitrary op]. Does anybody
use this. Would people object to requiring the operator after USING to
be part of an operator class?
Hmmm ... would this
Martijn van Oosterhout Wrote:
All we lose is the ability to say USING [arbitrary op]. Does
anybody
use this. Would people object to requiring the operator after
USING
to be part of an operator class?
Hmmm ... would this prevent the hackish workaround for
case-insensitive sort?
On Sun, Sep 18, 2005 at 04:19:06PM -0400, Andrew Dunstan wrote:
Err, which hackish workaround would that be? The right solution is
citext which creates it's own operator class. This doesn't have
anything to do with functional indexes either.
Last time I looked it appeared to have significant
On Mon, Sep 19, 2005 at 06:26:10AM +1000, John Hansen wrote:
I was actually of the impression that that was exacty what it was for:
specifying what op(class) to use for the sort in case you wanted to use
a non-default opclass for the type, and/or if the less-than operator
wasn't called ''.
On Sun, 18 Sep 2005, Jim C. Nasby wrote:
On Sat, Sep 17, 2005 at 01:40:28AM -0400, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 17 Sep 2005, Tom Lane wrote:
It'd be real interesting to see comparable numbers from some non-Linux
kernels, particularly commercial
Martijn van Oosterhout kleptog@svana.org writes:
On Mon, Sep 19, 2005 at 06:26:10AM +1000, John Hansen wrote:
I was actually of the impression that that was exacty what it was for:
specifying what op(class) to use for the sort in case you wanted to use
a non-default opclass for the type,
On P, 2005-09-18 at 18:04 -0400, Tom Lane wrote:
Another thing that's flaky in the current treatment is
the question of whether NULLs sort before or after ordinary values.
We've essentially tried to force NULLs to sort high (as if they
compare greater than all ordinary values), so that ASC and
Hannu Krosing [EMAIL PROTECTED] writes:
I think that placement of NULL's should be a property of ORDER BY and
separated from opclass.
That would be an extremely bad idea, because it would immediately remove
index scans as one way to meet an ORDER BY. I'm thinking in terms of
NULL high/low as
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I think that placement of NULL's should be a property of ORDER BY and
separated from opclass.
That would be an extremely bad idea, because it would immediately remove
index scans as one way to meet an ORDER BY. I'm thinking
Tom Lane [EMAIL PROTECTED] writes:
Hannu Krosing [EMAIL PROTECTED] writes:
I think that placement of NULL's should be a property of ORDER BY and
separated from opclass.
That would be an extremely bad idea, because it would immediately remove
index scans as one way to meet an ORDER BY.
Andrew Dunstan [EMAIL PROTECTED] writes:
Not sure I understand ... in fact I am sure I don't :-)
Are you envisioning that the null direction will be able to be selected
at the time of the select statement?
Yes, of course. My point is that we need to define operator class as
all you need to
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
That would be an extremely bad idea, because it would immediately remove
index scans as one way to meet an ORDER BY.
Well couldn't the index scan be taught to go fetch the NULLs in a separate
traversal?
(1) IS NULL
On Sun, 18 Sep 2005, Magnus Hagander wrote:
Having spent days, no, weeks deciding on that name on list I do not
want to see it change this late, especially as we'll now need to go
and update pgAdmin again!
Fortunately, pgAdmin doesn't use that function, but only the
basic pg_relation_size().
I think beta 2 is a good time to start fixing up the translations again.
As I had previously announced, long-time translators are invited to
register themselves at http://pgfoundry.org/projects/pgtranslation
and commit their work there. Those who do not want to do that can
continue to submit
21 matches
Mail list logo
