Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
>> To me the issue is what we consider IN and BETWEEN and similar
>> constructs to "mean", which in a datatype world boils down to choosing
>> which of the datatype's operators to implemen
On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > ISTM the problem is that there's no easy way to refer to "operators
> > found in a default opclass", so perhaps we could invent a construct:
>
> > A OPERATOR(btree,2) B
>
> Huh? I d
> Yes, but always in relation to operator classes, so from BTrees opclass or
> such, which I refered to as "the context of index searches", as I don't
> really see any theorical need for opclass if it's not for indexing.
IIRC analyze uses the btree op class to build the selectivity histogram.
-Na
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> ... I don't really see any theorical need for opclass if
> it's not for indexing.
Well, if we were starting from a green field, we might design it
differently, but I see little point in changing the system structure
now that it's established. You n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 25 août 08 à 16:48, Tom Lane a écrit :
But, IIRC, only in the context of index searches, not at the
planner level.
No, that's not true at all. There are lots and lots of places now
where
we use btree and/or hash operator classes to reas
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le lundi 25 août 2008, Gregory Stark a écrit :
>> I'm not sure it's made explicit anywhere in the documentation but those
>> properties *are* what btree operator classes define. You would end up
>> duplicating the same structures (like, LT is meaningle
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote:
>> My own feeling is that we should avoid imputing particular semantics
>> to particular operator names, and so these constructs should always be
>> defined by reference to operators found
On Monday 25 August 2008 04:24:23 Tom Lane wrote:
> Seems to me that what this boils down to is whether we want to read the
> spec literally ("it says the construct is defined in terms of operators
> named >= and <=, therefore we should do that") or by intent (obviously
> what they *want* is a cons
Le lundi 25 août 2008, Gregory Stark a écrit :
> I'm not sure it's made explicit anywhere in the documentation but those
> properties *are* what btree operator classes define. You would end up
> duplicating the same structures (like, LT is meaningless unless you
> associate it with the correspondin
"Dimitri Fontaine" <[EMAIL PROTECTED]> writes:
> Le lundi 25 août 2008, Martijn van Oosterhout a écrit :
>> ISTM the problem is that there's no easy way to refer to "operators
>> found in a default opclass", so perhaps we could invent a construct:
>
> Perhaps here again we're showing a need for so
Le lundi 25 août 2008, Martijn van Oosterhout a écrit :
> ISTM the problem is that there's no easy way to refer to "operators
> found in a default opclass", so perhaps we could invent a construct:
Perhaps here again we're showing a need for some higher level semantics about
operators and types. T
On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote:
> My own feeling is that we should avoid imputing particular semantics
> to particular operator names, and so these constructs should always be
> defined by reference to operators found in a default opclass for the
> datatype, rather than by
I was looking just now at gram.y's handling of various peculiar SQL
constructs, and was reminded of a point that's bothered me before,
but I don't recall if it's ever been discussed explicitly on -hackers.
As an example, take the production for BETWEEN ASYMMETRIC:
a_expr BETWEEN opt_a
13 matches
Mail list logo
