On Mon, Dec 26, 2005 at 15:12:48 -0500,
Gregory Maxwell <[EMAIL PROTECTED]> wrote:
> On 12/26/05, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > (1,1) <* (1,2) = true
> > (1,2) <* (2,1) is NULL
> > (2,3) <* (1,2) = false
> >
> > it's usefull for multicriterial optimalisation
>
> This is indeed a s
Greetings to all,
On Mon, Dec 26, 2005 at 10:04:59AM -0500, Tom Lane wrote:
> I would recommend posting some fairly detailed design discussions
> concerning what you see as the new semantics, API, and catalog
> representation for operators and operator classes. If you haven't
> got buy-in at that
On 12/26/05, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> (1,1) <* (1,2) = true
> (1,2) <* (2,1) is NULL
> (2,3) <* (1,2) = false
>
> it's usefull for multicriterial optimalisation
This is indeed a sane and useful function which should be adopted by
the SQL standard.. in postgresql this would easily
Huh? The only "current behavior" with other operators is failure:
you didn't understand me. I know so operator <* isn't supported now.
I prefere SQL spec behave too. But what I wont:
a <* b ~ ai <= bi and one ai < bi => true ; if one ai > bi => NULL; else
false
but this behave is from so
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
>> the SQL standard requires it to be processed as a column-by-column
>> comparison, so the proper comparison is '(a < 1) OR (a = 1 AND b < 2)'
> Can we save current behave (with smal
Martijn van Oosterhout writes:
> If you want technical details I can do that too (the summary on
> pg-patches a while ago is now wildly out of date). Currently I'm trying
> to get up to speed on pathkeys and indexes before the tree drifts too
> far...
I've given this advice before to other people
On Mon, Dec 26, 2005 at 01:29:19PM +0100, Pavel Stehule wrote:
> Can we save current behave (with small modification) with other operator,
> like <*
>
> (1,1) <* (1,2) = true
> (1,2) <* (2,1) is NULL
> (2,3) <* (1,2) = false
>
> it's usefull for multicriterial optimalisation
That's strange. Tha
TODO updated:
* %Make row-wise comparisons work per SQL spec
Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
the SQL standard requires it to be processed as a column-by-column
comparison, so the proper comparison is '(a < 1) OR (a = 1 AN
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Can someone explain to me how:
> > (a, b) < (1, 2)
> > is different to
> > a < 1 and b < 2
>
> Right at the moment our code interprets it that way, but this behavior
> is wrong per spec. It should be an ordered column-by-co
Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
>
> > > src/tools/make_ctags is your friend...
> >
> > That just shows you where a symbol is defined, not where it's called
> > from. When you change the parameters of a function, you need to make
> > sure you found all the places that used it
On Sat, Dec 24, 2005 at 09:38:23AM -0500, Tom Lane wrote:
> Are you suggesting that COLLATE will impose comparison semantics on
> all datatypes including non-string types? If so, I'd be interested
> to know what you have in mind. If not, claiming that it makes the
> issue go away is nonsensical.
Martijn van Oosterhout wrote:
> > src/tools/make_ctags is your friend...
>
> That just shows you where a symbol is defined, not where it's called
> from. When you change the parameters of a function, you need to make
> sure you found all the places that used it...
>
> IOW, it's good for going do
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Can someone explain to me how:
> (a, b) < (1, 2)
> is different to
> a < 1 and b < 2
Right at the moment our code interprets it that way, but this behavior
is wrong per spec. It should be an ordered column-by-column comparison,
so that the equ
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Now, since COLLATE support is still in progress, I'm not sure how much
>> any of this helps you. I'm up to modifying the scankeys but it's hard
>> when you jave to keep rgrepping the tree to work out what is called
>> from where...
> src/tools
Martijn van Oosterhout writes:
> One thing my COLLATE patch does is distinguish between collations and
> operator classes. So the reverse operator class issue disappears
> because it's just a collation and doesn't need a operator class
> (although it won't break anything, see below).
Are you sugg
On Sat, Dec 24, 2005 at 12:25:41PM +0100, Peter Eisentraut wrote:
> Am Samstag, 24. Dezember 2005 11:46 schrieb Martijn van Oosterhout:
> > That just shows you where a symbol is defined, not where it's called
> > from.
>
> I've never used ctags, but etags certainly do what you ask for.
Really? I'
Am Samstag, 24. Dezember 2005 11:46 schrieb Martijn van Oosterhout:
> That just shows you where a symbol is defined, not where it's called
> from.
I've never used ctags, but etags certainly do what you ask for.
---(end of broadcast)---
TIP 3: Have y
On Sat, Dec 24, 2005 at 06:05:58PM +0800, Christopher Kings-Lynne wrote:
> >Now, since COLLATE support is still in progress, I'm not sure how much
> >any of this helps you. I'm up to modifying the scankeys but it's hard
> >when you jave to keep rgrepping the tree to work out what is called
> >from
Now, since COLLATE support is still in progress, I'm not sure how much
any of this helps you. I'm up to modifying the scankeys but it's hard
when you jave to keep rgrepping the tree to work out what is called
from where...
src/tools/make_ctags is your friend...
Chris
--
On Fri, Dec 23, 2005 at 03:18:21PM -0500, Tom Lane wrote:
> I've gotten interested again in the issue of row comparisons, eg
> (a, b, c) >= (1, 2, 3)
> We've discussed this before, the most comprehensive thread being
> http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
> bu
I've gotten interested again in the issue of row comparisons, eg
(a, b, c) >= (1, 2, 3)
We've discussed this before, the most comprehensive thread being
http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
but nothing's gotten done. Unless someone's already working on thi
I've gotten interested again in the issue of row comparisons, eg
(a, b, c) >= (1, 2, 3)
We've discussed this before, the most comprehensive thread being
http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
but nothing's gotten done. Unless someone's already working on this
22 matches
Mail list logo
