Hello
2008/8/24 Martijn van Oosterhout [EMAIL PROTECTED]:
On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote:
So I feel that the proposal for labeled parameters as such is dead
in the water, and that the only usefulness this thread has had is
(re-) exploring the syntactic alternatives
2008/8/24 daveg [EMAIL PROTECTED]:
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
Hello
2008/8/23 Peter Eisentraut [EMAIL PROTECTED]:
On Friday 22 August 2008 07:41:30 Decibel! wrote:
If we're really worried about it we can have
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Why not just use some standard record syntax, like
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Hello
2008/8/24 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation -
Pavel Stehule [EMAIL PROTECTED] writes:
2008/8/23 Hannu Krosing [EMAIL PROTECTED]:
Why not just use some standard record syntax, like
do you thing, so is it simpler?
It's not about being simpler, it's about pointing out that there are
ways to do what you need without creating compatibility
2008/8/24 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/8/23 Hannu Krosing [EMAIL PROTECTED]:
Why not just use some standard record syntax, like
do you thing, so is it simpler?
It's not about being simpler, it's about pointing out that there are
ways to do what
On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote:
So I feel that the proposal for labeled parameters as such is dead
in the water, and that the only usefulness this thread has had is
(re-) exploring the syntactic alternatives available for named params.
FWIW, I think the way that
Hello
2008/8/22 Teodor Sigaev [EMAIL PROTECTED]:
How about we poll -general and see what people say? I'll bet Tom a beer
that no one replies saying they've created a = operator (unless maybe
PostGIS uses it).
Hstore uses it:
* text = text - creates hstore type from two text strings
Hello
2008/8/22 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
How about we poll -general and see what people say? I'll bet Tom a
beer that no one replies saying they've created a = operator (unless
maybe
On Friday 22 August 2008 07:41:30 Decibel! wrote:
If we're really worried about it we can have a GUC for a few versions
that turns off named parameter assignment. But I don't think we
should compromise the design on the theory that some folks might be
using that as an operator *and*
Hello
2008/8/23 Peter Eisentraut [EMAIL PROTECTED]:
On Friday 22 August 2008 07:41:30 Decibel! wrote:
If we're really worried about it we can have a GUC for a few versions
that turns off named parameter assignment. But I don't think we
should compromise the design on the theory that some
Pavel Stehule [EMAIL PROTECTED] writes:
Hello
2008/8/23 Peter Eisentraut [EMAIL PROTECTED]:
On Friday 22 August 2008 07:41:30 Decibel! wrote:
If we're really worried about it we can have a GUC for a few versions
that turns off named parameter assignment. But I don't think we
should
Pavel Stehule [EMAIL PROTECTED] writes:
I thing, so it's possible - in this case. We should transform named
params to expr after syntax analyze.
You're going to have a hard time making parentheses affect the behavior
if you do it that way.
regards, tom lane
--
Sent
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
Hello
2008/8/22 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
How about we poll -general and see what people say? I'll bet Tom a
beer that
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I thing, so it's possible - in this case. We should transform named
params to expr after syntax analyze.
You're going to have a hard time making parentheses affect the behavior
if you do it that way.
So for a bit of useless syntactic sugar we should introduce conflicts with
named parameters, conflicts with operators, introduce an un-sqlish syntax and
remove a feature users have already made use of and introduce backwards
compatibility issues for those users?
we talk only about = symbol.
At any point in this discussion has anyone explained why these
labels would
actually be a good idea?
it's allows smart libraries like SQL/XML
You could always just pass the label as an additional parameter. Which
is all this would be syntactic sugar for anyways. So it doesn't
allow
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Why not just use some standard record syntax, like
SELECT(value::type name, ...)
Yeah, that's
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
Hello
2008/8/23 Peter Eisentraut [EMAIL PROTECTED]:
On Friday 22 August 2008 07:41:30 Decibel! wrote:
If we're really worried about it we can have a GUC for a few versions
that
2008/8/23 Hannu Krosing [EMAIL PROTECTED]:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
Hello
2008/8/22 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
How about we poll -general and see
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
2008/8/20 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This
isn't
used so operator - so implementation is trivial.
You really didn't understand the objection
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
How about we poll -general and see what people say? I'll bet Tom a
beer that no one replies saying they've created a = operator (unless
maybe PostGIS uses it).
Does Oracle use = for
How about we poll -general and see what people say? I'll bet Tom a
beer that no one replies saying they've created a = operator (unless
maybe PostGIS uses it).
Hstore uses it:
* text = text - creates hstore type from two text strings
select 'a'='b';
?column?
--
a=b
--
Teodor
Would AS be harder to implement?
select foo(10 AS a, 20 AS b);
select foo(20 AS b, 20 AS a);
select x(0 = 1 AS a);
other fantasies
select foo(10 a, 20 b);
select foo(a 10, b 20);
regards,
Asko
On Wed, Aug 20, 2008 at 4:26 PM, Pavel Stehule [EMAIL PROTECTED]wrote:
2008/8/20 Tom Lane [EMAIL
2008/8/21 Asko Oja [EMAIL PROTECTED]:
Would AS be harder to implement?
select foo(10 AS a, 20 AS b);
select foo(20 AS b, 20 AS a);
select x(0 = 1 AS a);
other fantasies
select foo(10 a, 20 b);
select foo(a 10, b 20);
no, I have it. Problem is in semantic. There are two features, that
Hello
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
postgres=# create function x(a boolean) returns bool as $$select $1$$
language sql;
CREATE FUNCTION
Time: 5,549 ms
postgres=# select x(a = true);
x
---
t
(1 row)
Time:
Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
You really didn't understand the objection at all, did you?
The point is not about whether there is any built-in operator named =.
The
2008/8/20 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
You really didn't understand the objection at all, did you?
The point is not about whether
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
Hannu
it's not possible in plpgsql, because we are not able iterate via record.
just add function for iterating over record :)
it's not easy, when iterating should be fast - when record's
Am Saturday, 16. August 2008 schrieb Hannu Krosing:
A label is the same thing as variable/attribute/argument name in
all programming languages I can think of. Why do you need two kinds of
argument names in postgreSQL ?
maybe you are after something like keyword arguments in python ?
On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
Hannu
it's not possible in plpgsql, because we are not able iterate via record.
just add function for iterating over record :)
On Mon, 2008-08-18 at 10:51 +0300, Peter Eisentraut wrote:
Am Saturday, 16. August 2008 schrieb Hannu Krosing:
A label is the same thing as variable/attribute/argument name in
all programming languages I can think of. Why do you need two kinds of
argument names in postgreSQL ?
maybe
Is this a TODO?
---
Hannu Krosing wrote:
On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
Hannu
it's
On Mon, 2008-08-18 at 11:19 -0400, Bruce Momjian wrote:
Is this a TODO?
I don't think we have a TODO yet.
Maybe a TBD :)
---
Hannu Krosing wrote:
On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
2008/8/17
There may be a TODO in this thread somewhere, but I think this
particular suggestion has drifted pretty far from the problem that
Pavel was trying to solve.
...Robert
On Mon, Aug 18, 2008 at 11:19 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Is this a TODO?
it's not possible in plpgsql,
2008/8/16 Decibel! [EMAIL PROTECTED]:
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use value AS
On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
2008/8/16 Decibel! [EMAIL PROTECTED]:
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully
Hannu Krosing [EMAIL PROTECTED] writes:
Actually the most natural syntax to me is just f(name=value) similar
to how UPDATE does it. It has the added benefit of _not_ forcing us to
make a operator reserved (AFAIK = can't be used to define new ops)
*What* are you thinking?
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
2008/8/16 Decibel! [EMAIL PROTECTED]:
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new
On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Actually the most natural syntax to me is just f(name=value) similar
to how UPDATE does it. It has the added benefit of _not_ forcing us to
make a operator reserved (AFAIK = can't be used to define
Hannu
it's not possible in plpgsql, because we are not able iterate via record.
Pavel
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Actually the most natural syntax to me is just f(name=value) similar
Not able to means not implementable o not implemented ?
On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule [EMAIL PROTECTED]wrote:
Hannu
it's not possible inNot able to plpgsql, because we are not able iterate
via record.
Pavel
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17
Pavel Stehule [EMAIL PROTECTED] writes:
2008/8/17 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
2008/8/16 Decibel! [EMAIL PROTECTED]:
SQL-like would be value AS name, but I'm not a fan of putting the value
before the name. And I think value AS
2008/8/17 Asko Oja [EMAIL PROTECTED]:
Not able to means not implementable o not implemented ?
Almost not implementable - plpgsql is too static language.
On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule [EMAIL PROTECTED]
wrote:
Hannu
it's not possible inNot able to plpgsql, because we are
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
Hannu
it's not possible in plpgsql, because we are not able iterate via record.
just add function for iterating over record :)
create or replace function json(r record)
returns varchar as $$
select '[' || array_to_string(
array(
Actually the most natural syntax to me is just f(name=value) similar
to how UPDATE does it. It has the added benefit of _not_ forcing us to
make a operator reserved (AFAIK = can't be used to define new ops)
The problem with this is that
SELECT foo(a = b)
...is already valid syntax. It means
On Sun, 2008-08-17 at 18:24 -0400, Robert Haas wrote:
Actually the most natural syntax to me is just f(name=value) similar
to how UPDATE does it. It has the added benefit of _not_ forcing us to
make a operator reserved (AFAIK = can't be used to define new ops)
The problem with this is
uups, completely forgot dual use of = for both assignment and
comparison.
Maybe we can do without any keyword arguments or labeled function
params if we define a way to construct records in-place.
That sounds a lot cleaner to me.
something like
RECORD( 'Zdanek'::text AS name, 22::int AS
2008/8/15 Hannu Krosing [EMAIL PROTECTED]:
On Fri, 2008-08-15 at 14:54 +0200, Pavel Stehule wrote:
2008/8/15 Peter Eisentraut [EMAIL PROTECTED]:
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
I propose enhance current syntax that allows to specify label for any
function parameter:
Hello
2008/8/15 Hannu Krosing [EMAIL PROTECTED]:
On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Random googling shows me that Oracle appears to use a syntax like
name = value
This is actually a feature that I would like to see implemented
Pavel Stehule [EMAIL PROTECTED] writes:
or just use := operator?
You're still commandeering an operator name that wasn't reserved before.
This one doesn't even have the feeble excuse of being Oracle-compatible.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Saturday 16 August 2008 09:38:41 Pavel Stehule wrote:
because you have to write labels, where labels are equal with column
names. I would to add same comfort like SQL/XML functions.
Just a thought: You might be able to design this in some way to work on top of
named parameter calling.
On Sat, 2008-08-16 at 08:44 +0200, Pavel Stehule wrote:
Hello
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use value AS name or name AS
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use value AS name or name AS
value ?
IMHO, *natural*
2008/8/14 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
Hello
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
also fcename(localvar, ...) if called
2008/8/15 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want to use in the future for argument-name-based
parameter
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions like xmlforest function:
postgres=# select
2008/8/15 Peter Eisentraut [EMAIL PROTECTED]:
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions
Am Friday, 15. August 2008 schrieb Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want to use in the future for argument-name-based
Hello
2008/8/15 Peter Eisentraut [EMAIL PROTECTED]:
Am Friday, 15. August 2008 schrieb Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want
Peter Eisentraut [EMAIL PROTECTED] writes:
Random googling shows me that Oracle appears to use a syntax like
name = value
This is actually a feature that I would like to see implemented soonish, so
if
anyone has input on the possible syntax consequences, please comment.
We've been over
On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Random googling shows me that Oracle appears to use a syntax like
name = value
This is actually a feature that I would like to see implemented soonish, so
if
anyone has input on the
On Fri, 2008-08-15 at 14:54 +0200, Pavel Stehule wrote:
2008/8/15 Peter Eisentraut [EMAIL PROTECTED]:
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
Hello
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions like xmlforest function:
postgres=# select xmlforest(a) from foo;
xmlforest
---
a10/a
On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
Hello
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
also fcename(localvar, ...) if called from another function ?
How is this supposed
Hannu Krosing [EMAIL PROTECTED] writes:
How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want to use in the future for argument-name-based
parameter matching. The proposed behavior is not nearly
67 matches
Mail list logo
