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
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
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);
>
> i
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 i
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 mig
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?
On 25 Jan 2004, Greg Stark wrote:
> expression "a,b". It's "fixed" by just declaring "," special inside function
> calls. If you want to use the operator in the function call you have to use an
> extra set of parentheses.
Well, it would work. It's just that it felt like such a big hack that I
did
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 t
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
syn
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
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"
> The only question now is if it should be that we call the function with
> the variable x AS the value 13, or if we call the function with 13 AS the
> variable x. I.e.
...
> I don't know if one is more natural then the other in english. To my
> swedish ear both sounds as good. I like (x as 13) a
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
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.
> >
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,
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 operat
[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
> >
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, bu
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 l
19 matches
Mail list logo
