I agree with Tom on this. Good operator combinations
are hard to find when you are creating new operators.
= is a particularly good one.
Barring any override from the SQL200x standard,
I would strongly suggest AS, too.
elein
[EMAIL PROTECTED]
On Sun, Jan 25, 2004 at 02:54:12PM -0500, Tom Lane
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Peter Eisentraut [EMAIL PROTECTED] writes:
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
Yes, that does read well. And IS is already a keyword. We might have
Peter Eisentraut [EMAIL PROTECTED] writes:
Rod Taylor wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
On second thought though, it doesn't work.
select func(x is
On Mon, 26 Jan 2004, Tom Lane wrote:
If that was IS, then foo(x is 13) makes sense.
I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.
On second thought though, it doesn't work.
select func(x is null);
is ambiguous,
Matthew Kirkwood [EMAIL PROTECTED] writes:
... Perhaps:
select interest(amount := 500.0, rate := 1.3);
That might work, since := isn't a legal operator name. It might pose a
conflict for clients like ECPG that like to use :name as a parameter
indicator, but since we don't have an
I've been looking (and coded) a little bit on named function calls. Calls
on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined by the
user as an operator. It's not used as default in pg, but I just want to
tell you up front in case you don't
In article [EMAIL PROTECTED] you wrote:
I've been looking (and coded) a little bit on named function calls.
Calls on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined
by the user as an operator. It's not used as default in pg, but I
just
[EMAIL PROTECTED] (David Fetter) writes:
In article [EMAIL PROTECTED] you wrote:
I've been looking (and coded) a little bit on named function calls.
Calls on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined
by the user as an
On 25 Jan 2004, Greg Stark wrote:
foo (x = 13, y = 42)
Is it really necessary to steal it?
Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
clean way to fix that. Say that = is an operator
Greg Stark [EMAIL PROTECTED] writes:
I've been looking (and coded) a little bit on named function calls.
Calls on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined
by the user as an operator. It's not used as default in pg, but I
just want
On Sun, 25 Jan 2004, elein wrote:
Barring any override from the SQL200x standard,
I would strongly suggest AS, too.
I kind of like AS also now after thinking about it. The only reason for =
is that oracle used it, nothing else.
As I wrote in another mail, I will check out sql200x.
foo
Dennis Bjorklund [EMAIL PROTECTED] writes:
I kind of like AS also now after thinking about it. The only reason for =
is that oracle used it, nothing else.
Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses value AS type in some function-call
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
I kind of like AS also now after thinking about it. The only reason for =
is that oracle used it, nothing else.
Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses value AS type in
Dennis Bjorklund [EMAIL PROTECTED] writes:
On 25 Jan 2004, Greg Stark wrote:
foo (x = 13, y = 42)
Is it really necessary to steal it?
Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
Greg Stark [EMAIL PROTECTED] writes:
But the compatibility with Oracle would be awfully nice.
Perhaps I'm missing something here: why is compatibility with Oracle
here particularly worth worrying about? Supporting the same
functionality as Oracle is good, but ISTM supporting the exact same
Greg Stark [EMAIL PROTECTED] writes:
Of course it's ambiguous. Just as f(a,b) is ambiguous in C. It could
mean call f with two arguments, or it could mean call f with the
result of the expression a,b. It's fixed by just declaring ,
special inside function calls. If you want to use the operator
17 matches
Mail list logo
