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 sane and useful
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...
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 AND b
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. That's not
Martijn van Oosterhout kleptog@svana.org 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
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 small modification)
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 some views
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 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.
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
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
but
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 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
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
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've
Martijn van Oosterhout kleptog@svana.org 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).
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...
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 equivalent
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 down the
19 matches
Mail list logo
