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 http://svana.org/kleptog/
> Patent. n. Genius is 5% i
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
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 the
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
Martijn van Oosterhout writes:
> On Sun, Sep 18, 2005 at 11:23:01PM -0400, Tom Lane wrote:
>
> > 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 doe
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
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 s
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
On Sun, Sep 18, 2005 at 11:23:01PM -0400, Tom Lane wrote:
> 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 behav
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)
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 ne
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 O
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
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 a
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 AS
Martijn van Oosterhout 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, and/or if the le
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, 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 sign
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-insensiti
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 p
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
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 o
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 [2]
23 matches
Mail list logo
