much discussion on collation and ordering
I'm going to take from this discussion that there is no use for the
USING clause with operators not in an operator class and that if this
changes we won't be seriously inconveniencing anybody.
Have a nice day,
--
Martijn van Oosterhout
On Sun, Sep 18, 2005 at 11:23:01PM -0400, Tom Lane wrote:
snip
class families to relate opclasses for different datatypes. Basically
I'd like to solve most of these issues by constructing a new layer atop
opclasses, not by deciding that an opclass doesn't convey the full story
about the
On P, 2005-09-18 at 23:34 -0400, Tom Lane wrote:
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
On Mon, Sep 19, 2005 at 11:13:05AM +0300, Hannu Krosing wrote:
(1) IS NULL is not an indexable operation, so no, not without
significant overhaul of the index AM API.
But we do store NULLs in indexes, so why is it not indexable?
This is either an interface bug (not making use of stored
On E, 2005-09-19 at 11:24 +0200, Martijn van Oosterhout wrote:
On Mon, Sep 19, 2005 at 11:13:05AM +0300, Hannu Krosing wrote:
(1) IS NULL is not an indexable operation, so no, not without
significant overhaul of the index AM API.
But we do store NULLs in indexes, so why is it not
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Sep 18, 2005 at 11:23:01PM -0400, Tom Lane wrote:
snip
class families to relate opclasses for different datatypes. Basically
I'd like to solve most of these issues by constructing a new layer atop
opclasses, not by deciding that
Greg Stark [EMAIL PROTECTED] writes:
The thing is that these opclasses you're describing are closely related. It
ought to be possible to use a single index to produce results in any of the
four orders you describe.
Wrong --- only two of them. You can't magically swap nulls from one end
of the
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
The thing is that these opclasses you're describing are closely related. It
ought to be possible to use a single index to produce results in any of the
four orders you describe.
Wrong --- only two of them. You
On Mon, Sep 19, 2005 at 12:21:00PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
The thing is that these opclasses you're describing are closely related.
It
ought to be possible to use a single index to produce results in any of
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 ''.
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
23 matches
Mail list logo
