Martijn van Oosterhout writes:
> On Thu, Dec 29, 2005 at 04:33:32PM -, Andrew - Supernews wrote:
>> Does it matter? How would the same operator specify different orderings
>> in different operator classes,
> Well, we currently don't forbid it and indeed encourage it (by
> encouraging reverse
On Thu, Dec 29, 2005 at 04:33:32PM -, Andrew - Supernews wrote:
> On 2005-12-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Well, no, that's not the problem: the problem is that you should be able
> > to specify ORDER BY any sort ordering that the system can deal with, and
> > the USING syntax is
On Sun, Jan 01, 2006 at 07:48:56AM -, Andrew - Supernews wrote:
> Doesn't this result in incorrect output in multi-column sorts?
>
> i.e. if 'Foo' = 'foo', but for sorting purposes you always sort them
> with 'Foo' first, then a multicolumn sort of the following data:
>
> ('Foo',1)
> ('foo',2
On 2005-12-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, no, that's not the problem: the problem is that you should be able
> to specify ORDER BY any sort ordering that the system can deal with, and
> the USING syntax is in fact too impoverished to do that. What if the
> mentioned operator is in
On 2005-12-31, Martijn van Oosterhout wrote:
> You do bring up the possibility of secondary sort functions. Functions
> which are not involved in testing for equality, but provide addition
> sorting so that even in a case-insensetive sort, the different
> variations in case appear together. "All v
On Sat, Dec 31, 2005 at 02:54:18PM -0500, Tom Lane wrote:
> The example of case-insensitive sorting suggests that we need to assume
> that sort comparison functions can make finer-grained comparisons than
> the associated "equals" operator does. The current infrastructure
> forces these to be exac
Martijn van Oosterhout writes:
> On Sat, Dec 31, 2005 at 12:58:19AM -0500, Greg Stark wrote:
>> Two things are either the same or they aren't, and that can't change
>> based on context.
> So someone who wants a case-insensetive search actually doesn't want
> "Foo" to equal "foo"?
That nice simp
On Sat, Dec 31, 2005 at 12:58:19AM -0500, Greg Stark wrote:
> I think this is a mistake -- the same mistake that got us into trouble with
> Turkish.
>
> Hashing depends on the concept of equality which is integral to the type. Two
> things are either the same or they aren't, and that can't change
Martijn van Oosterhout writes:
> Yet hashing is also a property of the collation, not the type. The same
> string in different locales would hash differently.
I think this is a mistake -- the same mistake that got us into trouble with
Turkish.
Hashing depends on the concept of equality which i
On Fri, Dec 30, 2005 at 10:18:48AM -0500, Tom Lane wrote:
> I really need to study your mail from the other day, but unfortunately
> other pressures will probably keep me from getting to it today :-(.
> One comment though --- it's not really sane to include ASC/DESC in there
> is it? I thought the
Martijn van Oosterhout writes:
> On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
>> What I'd really like is to deprecate the "USING operator" syntax in
>> favor of a "USING operatorclassname" syntax. Actually, "USING opclass
>> [ASC/DESC]" would get the job done, since given an opclass
On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
> What I'd really like is to deprecate the "USING operator" syntax in
> favor of a "USING operatorclassname" syntax. Actually, "USING opclass
> [ASC/DESC]" would get the job done, since given an opclass you can
> certainly run the sort func
On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
> Well, no, that's not the problem: the problem is that you should be able
> to specify ORDER BY any sort ordering that the system can deal with, and
> the USING syntax is in fact too impoverished to do that. What if the
> mentioned operato
Martijn van Oosterhout writes:
> Hmm. By feature I assume you mean "ORDER BY ... USING" (which no-one
> could find an example of) and not "requiring the operator to be part of
> an opclass".
> In fact, I don't think we ever need to remove the syntax, just as long
> as the operator is part of an o
On Wed, Dec 28, 2005 at 07:38:36PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > The issue is whether anything you want to ORDER BY needs to be
> > described by an B-tree operator class, and hence have a real sort
> > function.
>
> I think it's reasonable to remove that feature, *af
Martijn van Oosterhout writes:
> The issue is whether anything you want to ORDER BY needs to be
> described by an B-tree operator class, and hence have a real sort
> function.
> 1. Do people have any problems with this?
> 2. Would a patch for this be accepted seperate from the whole collation
> s
Greetings everybody,
As part of the changes I would like relating to collations, the two
sort options in inlineApplySortFunction() using only a less-than
operator may become unsupportable. This has been indirectly discussed
before [1] and no-one seemed to have an issue with it then. Internally
not
17 matches
Mail list logo
