Joseph Adams joeyadams3.14...@gmail.com writes:
Here's a thought: suppose we did use the foo (name = value) syntax
for naming parameters. It could still be used in a very similar way
for hstore:
hstore(key1 = 'value1', key2 = 'value2')
No, that really isn't going to work: how will the
On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, that really isn't going to work: how will the parser know that the
names are not meant to match to actual named parameters of the function?
You could possibly do it with a special case for hstore() in the
grammar, but we
Greg Stark gsst...@mit.edu writes:
I wonder if we could offer something like VARIADIC but allows
arbitrarily named parameters which get passed in a hstore-like hash
instead of an array. Just thinking aloud here. I haven't thought about
what this would mean in the function call api.
Yeah, with
2010/6/5 Greg Stark gsst...@mit.edu:
On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, that really isn't going to work: how will the parser know that the
names are not meant to match to actual named parameters of the function?
You could possibly do it with a special case
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:
From a usability point of view, if we adopt the spec's syntax we have to
stop allowing = for any other purpose. Period.
What if we added a new dual type and limited the = operator only to that
type, being, essentially, a constructor. Then hstore
David E. Wheeler wrote:
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:
From a usability point of view, if we adopt the spec's syntax we have to
stop allowing = for any other purpose. Period.
What if we added a new dual type and limited the = operator only to that
type, being,
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams joeyadams3.14...@gmail.com wrote:
If I had to choose between = and := for parameter naming, I'd go with
:= because it seems more SQLish to me.
On second thought, = might actually be a very intuitive syntax for
defining dictionary types like hstore
Peter Eisentraut wrote:
On m?n, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
My feeling is that (a) there is no hurry to do anything about an
unreleased draft of the standard, and (b) perhaps Peter could lobby
the committee to change the standard before it does get published.
Given that
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
on zero notice is an acceptable outcome.
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
on zero notice is an
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
Bruce Momjian br...@momjian.us writes:
Is telling hstore users they have to change = to something else such a
large major version incompatibility that it is worth supporting and
documenting two syntaxes for parameter assignment? It is that calculus
that has me questioning our approach.
Well
Bruce Momjian br...@momjian.us writes:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix
On Jun 3, 2010, at 8:54 AM, Tom Lane wrote:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
Now that it's pretty clear from Peter that the standard is not going to
change its choice here, I'll vote adding a WARNING each time an operator
called = is created, so that we get a chance to move later on.
Should support for == be added to
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have
David E. Wheeler wrote:
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
Now that it's pretty clear from Peter that the standard is not going to
change its choice here, I'll vote adding a WARNING each time an operator
called = is created, so that we get a chance to move later on.
On 5/27/2010 11:52 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
Jan Wieck wrote:
That is a sad wart that we should never have done, IMNSHO (it was
before my time or I would have objected ;-) ). But beyond that, = is
an operator in SQL and := is never an operator, IIRC.
As far as I can tell, this was already in the code when Bruce moved it
into core
On mån, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
My feeling is that (a) there is no hurry to do anything about an
unreleased draft of the standard, and (b) perhaps Peter could lobby
the committee to change the standard before it does get published.
Given that Oracle and DB2 already support
Tom Lane wrote:
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs changes? If not, I'll pick it up.
If we eventually are going
2010/5/31 Bruce Momjian br...@momjian.us:
Tom Lane wrote:
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs changes? If not,
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs changes? If not, I'll
2010/5/31 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs
Bruce Momjian br...@momjian.us writes:
Yes, but if we are going to have to honor = eventually, shouldn't we
just do it now? Supporting := and = seems confusing.
Personally, I haven't accepted the if part of that, therefore I
feel no need to argue over the then.
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Yes, but if we are going to have to honor = eventually, shouldn't we
just do it now? Supporting := and = seems confusing.
Personally, I haven't accepted the if part of that, therefore I
feel no need to argue over the then.
Right, I
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not breaking hstore, as well as any third-party modules that might be
using that operator name. Did you not absorb any of the discussion
so far?
In fairness most of the discussion about breaking hstore was prior to
our
Greg Stark wrote:
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not breaking hstore, as well as any third-party modules that might be
using that operator name. ?Did you not absorb any of the discussion
so far?
In fairness most of the discussion about breaking
Greg Stark gsst...@mit.edu writes:
If = is sql standard syntax then perhaps that changes the calculus.
Well, it *isn't* standard, yet at least. All we have is a report of the
current wording of a draft that's at least a year from release.
regards, tom lane
--
Sent via
2010/5/31 Bruce Momjian br...@momjian.us:
Greg Stark wrote:
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not breaking hstore, as well as any third-party modules that might be
using that operator name. ?Did you not absorb any of the discussion
so far?
In fairness
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Yes, but if we are going to have to honor = eventually, shouldn't we
just do it now? Supporting := and = seems confusing.
Personally, I haven't accepted the if part of that, therefore I
feel no need to argue over the then.
Pavel Stehule wrote:
Part of the earlier discussion was about how = was a tempting
operator name and other users may well have chosen it precisely
because it's so evocative. But we don't actually have any evidence of
that. Does anyone have any experience seeing = operators in the wild?
2010/5/31 Bruce Momjian br...@momjian.us:
Pavel Stehule wrote:
Part of the earlier discussion was about how = was a tempting
operator name and other users may well have chosen it precisely
because it's so evocative. But we don't actually have any evidence of
that. Does anyone have any
Pavel Stehule wrote:
2010/5/31 Bruce Momjian br...@momjian.us:
Pavel Stehule wrote:
Part of the earlier discussion was about how = was a tempting
operator name and other users may well have chosen it precisely
because it's so evocative. But we don't actually have any evidence of
2010/5/31 Bruce Momjian br...@momjian.us:
Pavel Stehule wrote:
2010/5/31 Bruce Momjian br...@momjian.us:
Pavel Stehule wrote:
Part of the earlier discussion was about how = was a tempting
operator name and other users may well have chosen it precisely
because it's so evocative. But we
Bruce Momjian wrote:
MSSQL? Are you sure? This is the example posted in this thread:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
and it more matches our := syntax than = in its argument ordering.
I think you are seriously confused, or else you are seriously
Andrew Dunstan wrote:
Bruce Momjian wrote:
MSSQL? Are you sure? This is the example posted in this thread:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
and it more matches our := syntax than = in its argument ordering.
I think you are seriously confused,
Pavel Stehule pavel.steh...@gmail.com writes:
it's not important in this discussion. Important is using some usual
symbol '=' or special symbol '='. Our syntax is probably only one
possible solution in this moment (there are minimum controversy), bud
semantic isn't best. Using same operator as
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if :=
were to be used in this context for any other purpose, so I don't think we'd
be biting ourselves too much by just using that now. But if we do that, we
should
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if :=
were to be used in this context for any other purpose, so I don't think we'd
be biting ourselves too much by just using
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if :=
were to be used in this context for any other purpose, so I don't think
we'd
On Mon, May 31, 2010 at 9:24 PM, Florian Pflug f...@phlo.org wrote:
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if
:= were to
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
hstore already uses that for something else.
Robert's idea isn't a bad one if we're forced to rename the operator.
I'd still like to know
Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
hstore already uses that for something else.
Robert's idea isn't a bad one if we're forced to rename the operator.
On Mon, May 31, 2010 at 11:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
hstore already uses that for something else.
Robert's idea isn't a
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I'd still like to know exactly how hard the concrete has set on the
SQL spec draft, first. (Peter?)
I don't know, but based on the fact it matches Oracle, I think it is
pretty well set by now.
Eh? The SQL committee has a very long
2010/6/1 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
hstore already uses that for something else.
Robert's idea isn't a bad one if we're forced to
So as far as I can tell, no one is opposed to replacing expr AS name
with name := expr in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs changes? If not, I'll pick it up.
regards, tom lane
--
On 27/05/10 22:55, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
How about
select myfunc(a := 7, b := 6);
?
Hey, that's a thought. We couldn't have used that notation before
because we didn't have := as a separate token, but since I hacked that
in for plpgsql's benefit, I think it
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentrautpete...@gmx.net writes:
How about
select myfunc(a := 7, b := 6);
If we go with that, should we make some preparations to allow = in the
future? Like provide an alternative operator name for hstore's =, and
add
2010/5/28 Tom Lane t...@sss.pgh.pa.us:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentrautpete...@gmx.net writes:
How about
select myfunc(a := 7, b := 6);
If we go with that, should we make some preparations to allow = in the
future? Like provide an alternative
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentrautpete...@gmx.net writes:
How about
select myfunc(a := 7, b := 6);
If we go with that, should we make some preparations to allow = in the
future? Like provide an alternative
What's poor about it? It probably comes from PLSQL which in turn got it
from Ada, so they aren't just making this up. I agree it's inconvenient
for us, but that's a different issue.
Further, the
( parameter := value ) notation is not only consistent with what is used
inside pl/pgsql, it's
Josh Berkus wrote:
Since former SQL Server / Sybase apps are the most likely to use named
parameter notation in PostgreSQL, having a syntax which could be ported
using only sed would be nice.
Relevant to the whole discussion, though ... is the conflicting SQL
standard syntax something
Bruce Momjian wrote:
Josh Berkus wrote:
Since former SQL Server / Sybase apps are the most likely to use named
parameter notation in PostgreSQL, having a syntax which could be ported
using only sed would be nice.
Relevant to the whole discussion, though ... is the conflicting SQL
On 28/05/10 19:19, Josh Berkus wrote:
( parameter := value ) notation is not only consistent with what is used
inside pl/pgsql, it's also more consistent than AS with SQL Server's
named parameter notation, which is:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
Since former SQL
Josh Berkus j...@agliodbs.com writes:
Since former SQL Server / Sybase apps are the most likely to use named
parameter notation in PostgreSQL, having a syntax which could be ported
using only sed would be nice.
I fear you're vastly overestimating the ability of sed to distinguish
between =
Andrew Dunstan and...@dunslane.net writes:
Yeah. Whether or not we ever implement it really doesn't matter, IMO. We
should not be in the business of taking an SQL standard piece of syntax
and using it for some other purpose.
Evidently the 201x SQL standard has blindsided us twice: first by
On Fri, May 28, 2010 at 10:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/5/28 Tom Lane t...@sss.pgh.pa.us:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentrautpete...@gmx.net writes:
How about
select myfunc(a := 7, b := 6);
If we go with that, should
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 28/05/10 19:19, Josh Berkus wrote:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
Once you solve the problem of finding the '='s in the source, replacing them
is exactly the same effort regardless of what you replace
I think we should fix it now. Quick thought: maybe we could use FOR instead
of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for
this is 'paramname = value', but I think that has problems because of our
possibly use of = as an operator - otherwise that would be by far
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
2010/5/27 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator name. (And no, I'm not
for
2010/5/27 Robert Haas robertmh...@gmail.com:
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle uses
=, but as you said, that's ambiguous with the = operator.
+1 for FOR.
I don't see any advantage of FOR.
Any
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
I don't see any advantage of FOR. We can change ir to support new
standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's its only advantage. But I agree with you, I
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle
uses
=, but as you said, that's ambiguous with
2010/5/27 Abhijit Menon-Sen a...@toroid.org:
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
I don't see any advantage of FOR. We can change ir to support new
standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's
On 27/05/10 10:16, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
AFAIU, the standard doesn't say anything about named parameters. Oracle
uses
=,
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters.
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say
On tor, 2010-05-27 at 10:51 +0300, Heikki Linnakangas wrote:
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
2010/5/26 Peter Eisentraut pete...@gmx.net:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::=
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be interpreted as (for
example, to treat the value as a supertype).
Why don't they just use CAST() syntax for
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler da...@kineticode.com wrote:
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
Or we could use the Finnish word
epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
sure is not currently used in our grammar.
I thought that was an Icelandic volcano.
Best,
David
--
Sent via pgsql-hackers mailing list
On Thu, May 27, 2010 at 2:59 PM, David E. Wheeler da...@kineticode.com wrote:
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
Or we could use the Finnish word
epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
sure is not currently used in our grammar.
I thought that was an
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
select myfunc(a := 7, b := 6);
?
Hey, that's a thought. We couldn't have used
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Eisentraut pete...@gmx.net writes:
select myfunc(a := 7, b := 6);
Kinda like it myself.
Question #1: is the SQL committee likely to standardize that out
from under us, too?
Couldn't say on that one.
Question #2: will ecpg have a problem with
2010/5/27 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
select myfunc(a := 7, b := 6);
?
Hey,
On Thu, May 27, 2010 at 02:55:54PM -0400, Robert Haas wrote:
On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler da...@kineticode.com
wrote:
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined
Bruce Momjian wrote:
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll
Andrew Dunstan and...@dunslane.net writes:
Bruce Momjian wrote:
One concern I have is that in PL/pgSQL, := and = behave the same, while
in SQL, they would not. That might cause confusion.
I doubt there will be much confusion.
I agree. Bruce is ignoring the fact that they are *not*
Peter Eisentraut wrote:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::= left paren [ SQL
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname = value', but I think that has
problems
On May 26, 2010, at 4:09 PM, alvherre wrote:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice. Perhaps we could allow = to resolve as the
operator for the case the user really needs
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname = value', but
alvherre alvhe...@commandprompt.com writes:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice.
Sucks is not the word; utterly unacceptable is the word. Having an
expression mean
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
alvherre alvhe...@commandprompt.com writes:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice.
Sucks is not the
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?
As
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator name. (And no, I'm not
for that.)
I suppose the most painful thing
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator
99 matches
Mail list logo
