Thread: WIP: default values for function parameters

WIP: default values for function parameters

From
"Pavel Stehule"
Date:
Hello

I have problem with sending patch, so I am send link
http://www.pgsql.cz/patches/defaults.diff.gz

Example:
postgres=# create function fx(a int, b int default 30, c int default 40)
postgres-# returns int as $$ select $1 + $2 + $3; $$
postgres-# language sql;
CREATE FUNCTION
postgres=# select fx();
ERROR:  function fx() does not exist
LINE 1: select fx();             ^
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.
postgres=# select fx(10);fx
----80
(1 row)

postgres=# select fx(10,11);fx
----61
(1 row)

postgres=# select fx(10,11,12);fx
----33
(1 row)

Know bugs:
blind ambiguous call detection

comments, ideas?

regards
Pavel Stehule


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
Pavel Stehule wrote:
> I have problem with sending patch, so I am send link
> http://www.pgsql.cz/patches/defaults.diff.gz
> 
> Example:
> postgres=# create function fx(a int, b int default 30, c int default 40)

Could you explain why you store the default expressions in a new posexpr 
type rather than in an array of text (compare pg_attrdef.adbin)?



Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/24 Peter Eisentraut <peter_e@gmx.net>:
> Pavel Stehule wrote:
>>
>> I have problem with sending patch, so I am send link
>> http://www.pgsql.cz/patches/defaults.diff.gz
>>
>> Example:
>> postgres=# create function fx(a int, b int default 30, c int default 40)
>
> Could you explain why you store the default expressions in a new posexpr
> type rather than in an array of text (compare pg_attrdef.adbin)?
>
>

I would to implement named params - and there expressions, that are
used as default params, should not be continual. I don't store params
as array of text because I would to eliminate repeated expression's
parsing. So I use similar machanism used for rules or views.

Pavel


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/11/24 Peter Eisentraut <peter_e@gmx.net>:
>> Could you explain why you store the default expressions in a new posexpr
>> type rather than in an array of text (compare pg_attrdef.adbin)?

> I would to implement named params - and there expressions, that are
> used as default params, should not be continual. I don't store params
> as array of text because I would to eliminate repeated expression's
> parsing. So I use similar machanism used for rules or views.

Say again?  The representation Peter is suggesting *is* what is used
in rules and views.  If you've re-invented that wheel, undo it.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/24 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/11/24 Peter Eisentraut <peter_e@gmx.net>:
>>> Could you explain why you store the default expressions in a new posexpr
>>> type rather than in an array of text (compare pg_attrdef.adbin)?
>
>> I would to implement named params - and there expressions, that are
>> used as default params, should not be continual. I don't store params
>> as array of text because I would to eliminate repeated expression's
>> parsing. So I use similar machanism used for rules or views.
>
> Say again?  The representation Peter is suggesting *is* what is used
> in rules and views.  If you've re-invented that wheel, undo it.
>

Then I am blind. I store serialised transformed expression, but if
better solution exists, then I'll use it.

regards
Pavel Stehule

>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
> I would to implement named params - and there expressions, that are
> used as default params, should not be continual. I don't store params
> as array of text because I would to eliminate repeated expression's
> parsing. So I use similar machanism used for rules or views.

You mean you want to avoid repeated parsing of expressions in case the same 
expression is used as a default value for several parameters?  How common 
would that be?


Re: WIP: default values for function parameters

From
Alvaro Herrera
Date:
Pavel Stehule escribió:
> 2008/11/24 Tom Lane <tgl@sss.pgh.pa.us>:

> > Say again?  The representation Peter is suggesting *is* what is used
> > in rules and views.  If you've re-invented that wheel, undo it.
> 
> Then I am blind. I store serialised transformed expression, but if
> better solution exists, then I'll use it.

Seem to me you just want to store the output of nodeToString.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/24 Peter Eisentraut <peter_e@gmx.net>:
> On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
>> I would to implement named params - and there expressions, that are
>> used as default params, should not be continual. I don't store params
>> as array of text because I would to eliminate repeated expression's
>> parsing. So I use similar machanism used for rules or views.
>
> You mean you want to avoid repeated parsing of expressions in case the same
> expression is used as a default value for several parameters?  How common
> would that be?
>
no - I am reading default parameters in call statement parsing.
Default parameters are implemented similar to variadic functions - so
no changes on PL part - all changes are on caller part.

Pavel


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
> > You mean you want to avoid repeated parsing of expressions in case the
> > same expression is used as a default value for several parameters?  How
> > common would that be?
>
> no - I am reading default parameters in call statement parsing.
> Default parameters are implemented similar to variadic functions - so
> no changes on PL part - all changes are on caller part.

Then I don't understand why you need this special data type instead of using 
an array of text with nulls for parameters without default.


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/24 Peter Eisentraut <peter_e@gmx.net>:
> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>> > You mean you want to avoid repeated parsing of expressions in case the
>> > same expression is used as a default value for several parameters?  How
>> > common would that be?
>>
>> no - I am reading default parameters in call statement parsing.
>> Default parameters are implemented similar to variadic functions - so
>> no changes on PL part - all changes are on caller part.
>
> Then I don't understand why you need this special data type instead of using
> an array of text with nulls for parameters without default.
>

I expect some overhead with classic array - but this overhead will be
small and array of text with nulls is better variant, Tomorrow I'll
send updated version.

Regards
Pavel Stehule


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>> Default parameters are implemented similar to variadic functions - so
>> no changes on PL part - all changes are on caller part.

> Then I don't understand why you need this special data type instead of using 
> an array of text with nulls for parameters without default.

I'm not even sure you need to store any nulls.  We're going to require
defaults to be provided for the last N parameters consecutively, right?
So that's just what the array contents are.  Or maybe it's not an array
at all but a single text item containing the representation of a List
--- compare the storage of index expressions.  There shouldn't be any
need to read the contents of the value during function resolution;
an appropriate representation will have the number of non-defaultable
parameters stored as a separate integer column.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/25 Tom Lane <tgl@sss.pgh.pa.us>:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>>> Default parameters are implemented similar to variadic functions - so
>>> no changes on PL part - all changes are on caller part.
>
>> Then I don't understand why you need this special data type instead of using
>> an array of text with nulls for parameters without default.
>
> I'm not even sure you need to store any nulls.  We're going to require
> defaults to be provided for the last N parameters consecutively, right?
> So that's just what the array contents are.  Or maybe it's not an array
> at all but a single text item containing the representation of a List
> --- compare the storage of index expressions.  There shouldn't be any
> need to read the contents of the value during function resolution;
> an appropriate representation will have the number of non-defaultable
> parameters stored as a separate integer column.
>

this can be the most simple solution, I used special datatype because
a) I am afraid add more columns to system tables, b) I dislike
serialisation into text type, because simple select from this values
returns some "strange" values. But maybe I am thinking and searching
to much complicate solutions. I'll try to simplify patch.

Regards
Pavel Stehule

>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
Hello

I am sending actualized versions - I accepted Tom's comments - default
expressions are serialised List stored in text field.

Regards
Pavel Stehule

2008/11/25 Tom Lane <tgl@sss.pgh.pa.us>:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>>> Default parameters are implemented similar to variadic functions - so
>>> no changes on PL part - all changes are on caller part.
>
>> Then I don't understand why you need this special data type instead of using
>> an array of text with nulls for parameters without default.
>
> I'm not even sure you need to store any nulls.  We're going to require
> defaults to be provided for the last N parameters consecutively, right?
> So that's just what the array contents are.  Or maybe it's not an array
> at all but a single text item containing the representation of a List
> --- compare the storage of index expressions.  There shouldn't be any
> need to read the contents of the value during function resolution;
> an appropriate representation will have the number of non-defaultable
> parameters stored as a separate integer column.
>


>                        regards, tom lane
>

Attachment

Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
On Thursday 27 November 2008 00:14:19 Pavel Stehule wrote:
> I am sending actualized versions - I accepted Tom's comments - default
> expressions are serialised List stored in text field.

OK, this is looking pretty good.

There is a structural problem that we need to address.  With your patch, 
pg_dump produces something like this:

CREATE FUNCTION foo(a integer = 1, b integer = 2, c integer = 3) RETURNS 
integer   LANGUAGE sql   AS $_$ SELECT $1 + $2 + $3; $_$;

ALTER FUNCTION public.foo(a integer = 1, b integer = 2, c integer = 3) OWNER 
TO peter;


The second command is rejected because default values are only accepted in 
CREATE FUNCTION.

There are two ways to fix this, both having some validity:

1. We create a second version of pg_get_function_arguments() that produces 
arguments without default values decoration.  This is probably the 
technically sound thing to do.

2. We accept the default values specification and ignore it silently.  Note 
that we already silently ignore the argument names.  ALTER FUNCTION foo(a 
int, b int) will also act on a function defined as foo(x int, y int).

Comments?


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/30 Peter Eisentraut <peter_e@gmx.net>:
> On Thursday 27 November 2008 00:14:19 Pavel Stehule wrote:
>> I am sending actualized versions - I accepted Tom's comments - default
>> expressions are serialised List stored in text field.
>
> OK, this is looking pretty good.
>
> There is a structural problem that we need to address.  With your patch,
> pg_dump produces something like this:
>
> CREATE FUNCTION foo(a integer = 1, b integer = 2, c integer = 3) RETURNS
> integer
>    LANGUAGE sql
>    AS $_$ SELECT $1 + $2 + $3; $_$;
>
> ALTER FUNCTION public.foo(a integer = 1, b integer = 2, c integer = 3) OWNER
> TO peter;
>
>
> The second command is rejected because default values are only accepted in
> CREATE FUNCTION.
>
> There are two ways to fix this, both having some validity:
>
> 1. We create a second version of pg_get_function_arguments() that produces
> arguments without default values decoration.  This is probably the
> technically sound thing to do.
>
> 2. We accept the default values specification and ignore it silently.  Note
> that we already silently ignore the argument names.  ALTER FUNCTION foo(a
> int, b int) will also act on a function defined as foo(x int, y int).
>

if this variant is possible, then will be simply implemented

regard
Pavel

> Comments?
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> There are two ways to fix this, both having some validity:

> 1. We create a second version of pg_get_function_arguments() that produces 
> arguments without default values decoration.  This is probably the 
> technically sound thing to do.

Yes.  I think that the argument for allowing parameter names in commands
like ALTER FUNCTION is that the user might consider them part of the
function's identity.  This can hardly be claimed for default values.

Also, there's a third possibility: we could revert the decision to allow
pg_dump to depend on pg_get_function_arguments in the first place.  That
was really the lazy man's approach to begin with.  The more we allow
pg_dump to depend on backend functions that work in a SnapshotNow world,
the more risk we have of producing inconsistent dumps.
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Nov 30, 2008, at 6:49 PM, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
>> There are two ways to fix this, both having some validity:
>
>> 1. We create a second version of pg_get_function_arguments() that  
>> produces
>> arguments without default values decoration.  This is probably the
>> technically sound thing to do.
>
> Yes.  I think that the argument for allowing parameter names in  
> commands
> like ALTER FUNCTION is that the user might consider them part of the
> function's identity.  This can hardly be claimed for default values.

Agreed, default values should not be a part of function signatures,  
although it might be nice if ALTER FUNCTION to allow default values to  
be changed.

Best,

David


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/30 Tom Lane <tgl@sss.pgh.pa.us>:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> There are two ways to fix this, both having some validity:
>
>> 1. We create a second version of pg_get_function_arguments() that produces
>> arguments without default values decoration.  This is probably the
>> technically sound thing to do.

I'll prepare new patch with this change.

>
> Yes.  I think that the argument for allowing parameter names in commands
> like ALTER FUNCTION is that the user might consider them part of the
> function's identity.  This can hardly be claimed for default values.
>
> Also, there's a third possibility: we could revert the decision to allow
> pg_dump to depend on pg_get_function_arguments in the first place.  That
> was really the lazy man's approach to begin with.  The more we allow
> pg_dump to depend on backend functions that work in a SnapshotNow world,
> the more risk we have of producing inconsistent dumps.

I don't understand well. Transactions is spanish village for me. So
there will be some finalizing necessary from You or Peter.

Regards
Pavel Stehule

>
>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/11/30 Peter Eisentraut <peter_e@gmx.net>:
> On Thursday 27 November 2008 00:14:19 Pavel Stehule wrote:
>> I am sending actualized versions - I accepted Tom's comments - default
>> expressions are serialised List stored in text field.
>
> OK, this is looking pretty good.
>
> There is a structural problem that we need to address.  With your patch,
> pg_dump produces something like this:
>
> CREATE FUNCTION foo(a integer = 1, b integer = 2, c integer = 3) RETURNS
> integer
>    LANGUAGE sql
>    AS $_$ SELECT $1 + $2 + $3; $_$;
>
> ALTER FUNCTION public.foo(a integer = 1, b integer = 2, c integer = 3) OWNER
> TO peter;
>
>
> The second command is rejected because default values are only accepted in
> CREATE FUNCTION.
>
> There are two ways to fix this, both having some validity:
>
> 1. We create a second version of pg_get_function_arguments() that produces
> arguments without default values decoration.  This is probably the
> technically sound thing to do.

I did it. new version is attached

Regards
Pavel Stehule

>
> 2. We accept the default values specification and ignore it silently.  Note
> that we already silently ignore the argument names.  ALTER FUNCTION foo(a
> int, b int) will also act on a function defined as foo(x int, y int).
>
> Comments?
>

Attachment

Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
It's committed.


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/4 Peter Eisentraut <peter_e@gmx.net>:
> It's committed.
>

great,

thank you
Pavel


Re: WIP: default values for function parameters

From
Decibel!
Date:
On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote:
> Agreed, default values should not be a part of function signatures,  
> although it might be nice if ALTER FUNCTION to allow default values  
> to be changed.


It would be VERY nice. I routinely cut and paste an entire function  
header to later perform things like ALTER and GRANT so that I don't  
have to re-type everything. It would be a huge PITA if I had to then  
go and delete any default settings.

Example:

CREATE OR REPLACE FUNCTION add(a int, b int
) RETURNS int LANGUAGE ...

GRANT EXECUTE ON FUNCTION add(a int, b int
) TO someuser;
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828




Re: WIP: default values for function parameters

From
Grzegorz Jaskiewicz
Date:
if I may request one simple change/addition, Probably trivial to add,  
but I don't have too much time to give away now to any other project  
than one that pays my debts.
The default param that's in the middle. Would it be hard, or do anyone  
objects against adding 'default' keyword there, so one doesn't have to  
substitute default param 3, when he only wants to override 2nd in  
funct(1,2,3) ?



Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Grzegorz Jaskiewicz <gj@pointblue.com.pl>:
> if I may request one simple change/addition, Probably trivial to add, but I
> don't have too much time to give away now to any other project than one that
> pays my debts.
> The default param that's in the middle. Would it be hard, or do anyone
> objects against adding 'default' keyword there, so one doesn't have to
> substitute default param 3, when he only wants to override 2nd in
> funct(1,2,3) ?
>
>

I don't plan it, or not yet, because I don't would to complicate rules
for using it. But for 8.5 I prepare named notation and maybe mixed
notation. like param1 => some, param2 => some ..

Regards
Pavel Stehule


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
Decibel! wrote:
> On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote:
>> Agreed, default values should not be a part of function signatures, 
>> although it might be nice if ALTER FUNCTION to allow default values to 
>> be changed.

> It would be VERY nice. I routinely cut and paste an entire function 
> header to later perform things like ALTER and GRANT so that I don't have 
> to re-type everything. It would be a huge PITA if I had to then go and 
> delete any default settings.

That is not what David was talking about above.

Currently, I don't think you can change parameter default values of an 
existing function.  But I think that would be a useful and 
uncontroversial addition.


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
Grzegorz Jaskiewicz wrote:
> if I may request one simple change/addition, Probably trivial to add, 
> but I don't have too much time to give away now to any other project 
> than one that pays my debts.
> The default param that's in the middle. Would it be hard, or do anyone 
> objects against adding 'default' keyword there, so one doesn't have to 
> substitute default param 3, when he only wants to override 2nd in 
> funct(1,2,3) ?

I don't really understand what you are talking about, but if you mean 
allowing default values in the middle of a parameter list, then I'd say 
rather not.


Re: WIP: default values for function parameters

From
Grzegorz Jaskiewicz
Date:
Ok, how about

CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[]  
default '{6,7,8,90}')....;

and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');

I have no idea what SQL standard says in that case, all I know is that  
keyword DEFAULT exists in it, and is used in queries for similar  
purpose.



Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
Grzegorz Jaskiewicz wrote:
> Ok, how about
> 
> CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] 
> default '{6,7,8,90}')....;
> 
> and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');

Yeah, that could be a useful feature.


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Grzegorz Jaskiewicz <gj@pointblue.com.pl> writes:
> The default param that's in the middle. Would it be hard, or do anyone  
> objects against adding 'default' keyword there, so one doesn't have to  
> substitute default param 3, when he only wants to override 2nd in  
> funct(1,2,3) ?

Yes, and yes.  We can only allow eliminating parameters from the right,
else it becomes impossibly ambiguous.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Grzegorz Jaskiewicz <gj@pointblue.com.pl>:
> Ok, how about
>
> CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] default
> '{6,7,8,90}')....;
>
> and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
>
> I have no idea what SQL standard says in that case, all I know is that
> keyword DEFAULT exists in it, and is used in queries for similar purpose.
>
>

SQL standard don't say anything. Leader (in this topic)  is Oracle,
and there is for this case "mixed notation" (google) -

select foo(777, three=> '{1,2,3,4,5});

it's more safe and more readable.

I did some test, and I thing so it is implementable. I had to solve
problem with hstore module. There is defined operator => too, what is
bad. But we can implemented in transformation and it should by
disabled via GUC, so it's solveable.

reagards
Pavel Stehule


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> select foo(777, three=> '{1,2,3,4,5});

> it's more safe and more readable.

... and it breaks an operator that's already in use.

> I did some test, and I thing so it is implementable. I had to solve
> problem with hstore module. There is defined operator => too, what is
> bad. But we can implemented in transformation and it should by
> disabled via GUC, so it's solveable.

What's wrong with the "expr AS parameter_name" syntax that we've
discussed before?  (And no, having a GUC that changes the meaning
of "=>" isn't an acceptable workaround.)
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> select foo(777, three=> '{1,2,3,4,5});
>
>> it's more safe and more readable.
>
> ... and it breaks an operator that's already in use.
>
>> I did some test, and I thing so it is implementable. I had to solve
>> problem with hstore module. There is defined operator => too, what is
>> bad. But we can implemented in transformation and it should by
>> disabled via GUC, so it's solveable.
>
> What's wrong with the "expr AS parameter_name" syntax that we've
> discussed before?  (And no, having a GUC that changes the meaning
> of "=>" isn't an acceptable workaround.)
>

what is acceptable workaround? I unhappy, so this symbol was used for
this minor contrib module (for this operator doesn't exists regress
test).

a) "AS" is used in diferent meaning now [rename] (SQL/XML), labels
b) when we implemented, then we blocking possible way, when ANSI SQL
generalise current behave
c) it's own syntax that will be muddly (viz a.)
d) both mayor databases has syntax name symbol value

@name = value
name => value

I am searching ways (or syntax) for two features named params, and
named values. Last are inspirated SQL/XML that is great (I know, so
your opinion is different). For export functions I need to send some
information about columns or labels into functions. So it's usable for
custom export functions, JSON implementation, maybe for
communications.

regards
Pavel Stehule



>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>> ... and it breaks an operator that's already in use.

> what is acceptable workaround? I unhappy, so this symbol was used for
> this minor contrib module (for this operator doesn't exists regress
> test).

If you could prove that it were *only* being used by this contrib module
then I might hold still for replacing it.  But you can't.  The odds are
good that people have custom data types using similarly-named operators.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>>> ... and it breaks an operator that's already in use.
>
>> what is acceptable workaround? I unhappy, so this symbol was used for
>> this minor contrib module (for this operator doesn't exists regress
>> test).
>
> If you could prove that it were *only* being used by this contrib module
> then I might hold still for replacing it.  But you can't.  The odds are
> good that people have custom data types using similarly-named operators.

it means, so we must not implement any new operator?

regards
Pavel Stehule

>
>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>> If you could prove that it were *only* being used by this contrib module
>> then I might hold still for replacing it.  But you can't.  The odds are
>> good that people have custom data types using similarly-named operators.

> it means, so we must not implement any new operator?

No, it doesn't mean any such thing.  If we invented, say, "int4 => int4"
it would not break someone's use of => for their own custom datatype.
What you're proposing would be a global redefinition of the meaning of =>.

This is closer to creating a new reserved word, which as I'm sure you
know we try hard to avoid, even for keywords that the spec says we can
reserve.  The bar for making a new fully-reserved word that isn't in
the spec is *very* high.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Robert Haas"
Date:
> it means, so we must not implement any new operator?

If the operator were called %@==+!, I think you could make a good
argument that no one else is likely using that for anything.

Surely the same cannot be said of =>

Of course, %@==+! is not a very convenient name for an operator, but
that's exactly the point: there are only a limited number of good,
short names for operators, and => must be near the top of that list.

...Robert


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>>> If you could prove that it were *only* being used by this contrib module
>>> then I might hold still for replacing it.  But you can't.  The odds are
>>> good that people have custom data types using similarly-named operators.
>
>> it means, so we must not implement any new operator?
>
> No, it doesn't mean any such thing.  If we invented, say, "int4 => int4"
> it would not break someone's use of => for their own custom datatype.
> What you're proposing would be a global redefinition of the meaning of =>.

it's not true, because anybody could to define own operator on buildin
types - so every new operator is risk and carry problems. So only new
operator on new types are safe. All others shoud be problem - an using
of any well know world carries risks.

>
> This is closer to creating a new reserved word, which as I'm sure you
> know we try hard to avoid, even for keywords that the spec says we can
> reserve.  The bar for making a new fully-reserved word that isn't in
> the spec is *very* high.
>

what is problematic on GUC? We use it actually for it? So we should
disable or enable named_params, and when this feature will be
disabled, then pg will be 100% compatible. It's better then creating
some strange syntax.

regards
Pavel

>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> what is problematic on GUC?

Basically, it's a bad idea to have GUCs that silently make significant
changes in the syntactic meaning of a query.  We've learned that lesson
the hard way I think.  There are places where we've been forced to do
it because of priority-one considerations like standards compatibility
(eg, standard_conforming_strings).  This proposed feature doesn't carry
anywhere near the weight that would make me willing to put in another
such wart.
        regards, tom lane


Re: WIP: default values for function parameters

From
Gregory Stark
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:

> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> 2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
>>>> ... and it breaks an operator that's already in use.
>>
>>> what is acceptable workaround? I unhappy, so this symbol was used for
>>> this minor contrib module (for this operator doesn't exists regress
>>> test).
>>
>> If you could prove that it were *only* being used by this contrib module
>> then I might hold still for replacing it.  But you can't.  The odds are
>> good that people have custom data types using similarly-named operators.
>
> it means, so we must not implement any new operator?

Operators mean something specific in Postgres. You're talking about
implementing a new fundamental syntax but using a token that's
indistinguishable from the set of operators.

This is a case where Postgres and these other databases have just diverged and
copying their syntax would break with Postgres's in a major way. It just
doesn't fit. Consider for example things like

foo => bar
foo =>= bar
foo @> bar

How would a user recognise which of these are legal operator names?

Incidentally -- EDB selling Oracle compatibility may put me in a questionable
position here -- the more Oracle incompatibilities in stock Postgres the
better for us. But afaik we don't emulate => anyways so that hardly matters.
If anything it shows how unimportant it is to worry about being compatible on
this front.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
>
> How would a user recognise which of these are legal operator names?
>
> Incidentally -- EDB selling Oracle compatibility may put me in a questionable
> position here -- the more Oracle incompatibilities in stock Postgres the
> better for us. But afaik we don't emulate => anyways so that hardly matters.
> If anything it shows how unimportant it is to worry about being compatible on
> this front.
>

I don't search compatibility - just searching any good syntax. And
Oracle used wide used syntax - from Ada, Perl. - It isn't Oracle
patent or Oracle design. And named params hasn't big sense without
default params. So now is time for speaking about it.

look on ADA http://archive.adaic.com/standards/83rat/html/ratl-08-03.html

PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
And it is my goal.

Regards
Pavel Stehule

> --
>  Gregory Stark
>  EnterpriseDB          http://www.enterprisedb.com
>  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
> And it is my goal.

[ shrug... ]  Don't be too surprised when the patch gets rejected.
Oracle compatibility is nice when we can get it, but we aren't going
to break existing behavior for it.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
>> And it is my goal.
>
> [ shrug... ]  Don't be too surprised when the patch gets rejected.
> Oracle compatibility is nice when we can get it, but we aren't going
> to break existing behavior for it.
>

I believe to GUC should be a solution - I am don't understand your
argument (wrong historic implementation isn't strong argument*), so ..
I am not hurry, and maybe somebody will come with less controversal
solution or beter solution, maybe not. Actually - variadic functions
and defaults are significant step to forward and will carry comfort to
application and library programmers. And I thing so named params or
argument's metadata is logical next step. I should to believe so
implementation will be in conformance with current standard and with
ideas of standard. I invite any ideas, and I will diskus about it with
respect to ADA (as origin lot of SQL construct) and, ofcourse,
standard.

Really - my goal isn't Oracle compatibility (it's only one efect,
because Oracle use well syntax). I am primary working on libraries and
external modules - and my work (variadic fce, defaults) started on
JSON support. Is nice on PostgreSQL, so every feature should be
customised - own objects, operators, agregates - so I would to write
similar functions (with same user comfort) to SQL/XML function
(without parser's patching) - it isn't possible now.

best regards
Pavel Stehule

p.s.
you can see on cvs - there are some people that develops or use orafce
much more hard then me

* a) this feature should be disabled in default b) should be conditional compiled c) with two, three hooks and some
smallchanges should be
 
implemented as external (contrib) module ~ the most worst variant

>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Bruce Momjian
Date:
Pavel Stehule wrote:
> >
> > How would a user recognise which of these are legal operator names?
> >
> > Incidentally -- EDB selling Oracle compatibility may put me in a questionable
> > position here -- the more Oracle incompatibilities in stock Postgres the
> > better for us. But afaik we don't emulate => anyways so that hardly matters.
> > If anything it shows how unimportant it is to worry about being compatible on
> > this front.
> >
> 
> I don't search compatibility - just searching any good syntax. And
> Oracle used wide used syntax - from Ada, Perl. - It isn't Oracle
> patent or Oracle design. And named params hasn't big sense without
> default params. So now is time for speaking about it.
> 
> look on ADA http://archive.adaic.com/standards/83rat/html/ratl-08-03.html
> 
> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
> And it is my goal.

Well, that is interesting, but in SQL we already use 'AS' in most places
where we want to assign a label to a value, so it seems AS is more
logical for SQL at this point.

The problem with a GUC is that when it is changed it breaks things and
it might be set in a dump file but not in postgresql.conf;  there is a
long list of problems we have encountered when changing SQL semenatics
via GUC, autocommit being one of them.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Bruce Momjian <bruce@momjian.us>:
> Pavel Stehule wrote:
>> >
>> > How would a user recognise which of these are legal operator names?
>> >
>> > Incidentally -- EDB selling Oracle compatibility may put me in a questionable
>> > position here -- the more Oracle incompatibilities in stock Postgres the
>> > better for us. But afaik we don't emulate => anyways so that hardly matters.
>> > If anything it shows how unimportant it is to worry about being compatible on
>> > this front.
>> >
>>
>> I don't search compatibility - just searching any good syntax. And
>> Oracle used wide used syntax - from Ada, Perl. - It isn't Oracle
>> patent or Oracle design. And named params hasn't big sense without
>> default params. So now is time for speaking about it.
>>
>> look on ADA http://archive.adaic.com/standards/83rat/html/ratl-08-03.html
>>
>> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
>> And it is my goal.
>
> Well, that is interesting, but in SQL we already use 'AS' in most places
> where we want to assign a label to a value, so it seems AS is more
> logical for SQL at this point.

Question is - what is label - is it parameter name or some other value?

Every output in SQL has default label - column name, or some default.
And we use "AS" for change this default label. So using AS for param
names is bad idea.

Please, show me other case.

>
> The problem with a GUC is that when it is changed it breaks things and
> it might be set in a dump file but not in postgresql.conf;  there is a
> long list of problems we have encountered when changing SQL semenatics
> via GUC, autocommit being one of them.

ofcourse, users have to use own mind - but it not break postgresql
using. GUC allow implement new feature in some steps. Actually it's
used for standard literals, and I don't know about any problems.

Autocommit is different case - it's invisible but important change.
Named params change syntax and impact is much more less than moving
tsearch2 to core.

regards
Pavel Stehule

>
> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>


Re: WIP: default values for function parameters

From
Bruce Momjian
Date:
Pavel Stehule wrote:
> >> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
> >> And it is my goal.
> >
> > Well, that is interesting, but in SQL we already use 'AS' in most places
> > where we want to assign a label to a value, so it seems AS is more
> > logical for SQL at this point.
> 
> Question is - what is label - is it parameter name or some other value?
> 
> Every output in SQL has default label - column name, or some default.
> And we use "AS" for change this default label. So using AS for param
> names is bad idea.
> 
> Please, show me other case.

Well, we use AS in the FROM clause to label tables and those labels can
be used to reference the table in other places in the query.  I see us
using AS here as a way to assign the contant to a label that is
referenced as a function parameter.

> > The problem with a GUC is that when it is changed it breaks things and
> > it might be set in a dump file but not in postgresql.conf;  there is a
> > long list of problems we have encountered when changing SQL semenatics
> > via GUC, autocommit being one of them.
> 
> ofcourse, users have to use own mind - but it not break postgresql
> using. GUC allow implement new feature in some steps. Actually it's
> used for standard literals, and I don't know about any problems.
> 
> Autocommit is different case - it's invisible but important change.
> Named params change syntax and impact is much more less than moving
> tsearch2 to core.

The problem is that function text might rely on a certain setting of the
GUC and unless the function sets the GUC itself it could break
functions.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Bruce Momjian <bruce@momjian.us>:
> Pavel Stehule wrote:
>> >> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural.
>> >> And it is my goal.
>> >
>> > Well, that is interesting, but in SQL we already use 'AS' in most places
>> > where we want to assign a label to a value, so it seems AS is more
>> > logical for SQL at this point.
>>
>> Question is - what is label - is it parameter name or some other value?
>>
>> Every output in SQL has default label - column name, or some default.
>> And we use "AS" for change this default label. So using AS for param
>> names is bad idea.
>>
>> Please, show me other case.
>
> Well, we use AS in the FROM clause to label tables and those labels can
> be used to reference the table in other places in the query.  I see us
> using AS here as a way to assign the contant to a label that is
> referenced as a function parameter.

this is still change of existing label - and it's argument for me - it
is label - not name of argument.

you cannot call function in postgresql in any other context
(PostgreSQL doesn't support statement CALL), so every AS sets label
for given value. You change property of some constant.

Or we should to go via Perl way, where every operator has different
meaning in different content (but I hope, so not).

SELECT column AS bbbb from foo; AS specifies other label than column name
SELECT sin(column AS bbb) from foo; ---> so it reason why using AS for
param names is wrong, with change of context I changing meaning.


>
>> > The problem with a GUC is that when it is changed it breaks things and
>> > it might be set in a dump file but not in postgresql.conf;  there is a
>> > long list of problems we have encountered when changing SQL semenatics
>> > via GUC, autocommit being one of them.
>>
>> ofcourse, users have to use own mind - but it not break postgresql
>> using. GUC allow implement new feature in some steps. Actually it's
>> used for standard literals, and I don't know about any problems.
>>
>> Autocommit is different case - it's invisible but important change.
>> Named params change syntax and impact is much more less than moving
>> tsearch2 to core.
>
> The problem is that function text might rely on a certain setting of the
> GUC and unless the function sets the GUC itself it could break
> functions.
>

can you show sample?

> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/12/10 Bruce Momjian <bruce@momjian.us>:
>> Well, that is interesting, but in SQL we already use 'AS' in most places
>> where we want to assign a label to a value, so it seems AS is more
>> logical for SQL at this point.

> Question is - what is label - is it parameter name or some other value?

> Every output in SQL has default label - column name, or some default.
> And we use "AS" for change this default label. So using AS for param
> names is bad idea.

That argument is complete nonsense.  A function parameter can't possibly
be an "output" of a SQL statement, so there is no conflict.
        regards, tom lane


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> look again
> select c as foo from tab ...
> select fce(c as foo) from tab ...

> when you use AS as param names specification, you change meaning of
> some construct via used context?

Uh, what's your point?  AS changes the meaning too.  For example in

select foo, bar from (select c as foo, d as bar from ...) ss;

we are using AS to specify the names seen by the outer select.
This seems to me to be quite a close parallel to attaching names
to function parameters.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/12/10 Bruce Momjian <bruce@momjian.us>:
>>> Well, that is interesting, but in SQL we already use 'AS' in most places
>>> where we want to assign a label to a value, so it seems AS is more
>>> logical for SQL at this point.
>
>> Question is - what is label - is it parameter name or some other value?
>
>> Every output in SQL has default label - column name, or some default.
>> And we use "AS" for change this default label. So using AS for param
>> names is bad idea.
>
> That argument is complete nonsense.  A function parameter can't possibly
> be an "output" of a SQL statement, so there is no conflict.
>

we speaking about two things probably. I speaking so using AS in two
independent meaning is wrong.

look again
select c as foo from tab ...
select fce(c as foo) from tab ...

when you use AS as param names specification, you change meaning of
some construct via used context?

is it true or false?

regards
Pavel Stehule


>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> look again
>> select c as foo from tab ...
>> select fce(c as foo) from tab ...
>
>> when you use AS as param names specification, you change meaning of
>> some construct via used context?
>
> Uh, what's your point?  AS changes the meaning too.  For example in
>
> select foo, bar from (select c as foo, d as bar from ...) ss;
>
> we are using AS to specify the names seen by the outer select.
> This seems to me to be quite a close parallel to attaching names
> to function parameters.

no, no - you use AS for an change of some property of set c column
values - label. Isn't important if this is select, subselect. label is
metadata - it's related to data. This is using of AS. Maybe it's
different for me, because I am not native speaker, so I feeling SQL
more like artifical language than you. For you using AS is more less
formal - it's your natural language. So I am filling some border
between data names (labels) and parameter names.

next argument - if we accept AS for param names, then we introduce
nonconsistent behave with SQL/XML functions.

select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean
"use it as param foo", so from this view is using AS very dificult
accaptable too.

regards
Pavel Stehule

>
>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> next argument - if we accept AS for param names, then we introduce
> nonconsistent behave with SQL/XML functions.

> select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean
> "use it as param foo",

It could be read as meaning that, I think.

In any case, I'm not wedded to using AS for this, and am happy to
consider other suggestions.  But => isn't acceptable.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> next argument - if we accept AS for param names, then we introduce
>> nonconsistent behave with SQL/XML functions.
>
>> select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean
>> "use it as param foo",
>
> It could be read as meaning that, I think.
>
> In any case, I'm not wedded to using AS for this, and am happy to
> consider other suggestions.

me too

regards
Pavel Stehule

But => isn't acceptable.
>
>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/10 Pavel Stehule <pavel.stehule@gmail.com>:
> 2008/12/10 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> next argument - if we accept AS for param names, then we introduce
>>> nonconsistent behave with SQL/XML functions.
>>
>>> select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean
>>> "use it as param foo",
>>
>> It could be read as meaning that, I think.
>>
>> In any case, I'm not wedded to using AS for this, and am happy to
>> consider other suggestions.

what do you thing about?

select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)

example
select dosome(10,20,30, SET flaga = true, flagb = false)

regards
Pavel Stehule

>
> me too
>
> regards
> Pavel Stehule
>
> But => isn't acceptable.
>>
>>                        regards, tom lane
>>
>


Re: WIP: default values for function parameters

From
Bruce Momjian
Date:
Pavel Stehule wrote:
> 2008/12/10 Pavel Stehule <pavel.stehule@gmail.com>:
> > 2008/12/10 Tom Lane <tgl@sss.pgh.pa.us>:
> >> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> >>> next argument - if we accept AS for param names, then we introduce
> >>> nonconsistent behave with SQL/XML functions.
> >>
> >>> select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean
> >>> "use it as param foo",
> >>
> >> It could be read as meaning that, I think.
> >>
> >> In any case, I'm not wedded to using AS for this, and am happy to
> >> consider other suggestions.
> 
> what do you thing about?
> 
> select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
> 
> example
> select dosome(10,20,30, SET flaga = true, flagb = false)

I think AS read more naturally because you expect the parameter to come
first, not the SET keyword.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> what do you thing about?

> select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)

I'm not really seeing any redeeming social value in that.  It's more
keystrokes than the other; and if you dislike AS because of possible
confusion with other usages then surely the same objection applies to
SET.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Kevin Grittner"
Date:
>>> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> In any case, I'm not wedded to using AS for this, and am happy to
> consider other suggestions.  But => isn't acceptable.
How about using a bare equals sign (or the => characters) for
parameter assignment, but require that the parameter name be prefixed
with some special character?  (My first thought was a dollar sign, but
that would cause problems in PL/pgSQL, so some other character would
need to be used.)   It seems like that could give the parser enough
context to consider the operator as parameter assignment, so it
wouldn't require making it a fully reserved word or preclude other
uses of the operator.
I guess it would preclude the use of whatever character was chosen as
a prefix operator in the context of a parameter list, however; which
might be a fatal flaw to the idea.
-Kevin


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/11 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> what do you thing about?
>
>> select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
>
> I'm not really seeing any redeeming social value in that.  It's more
> keystrokes than the other; and if you dislike AS because of possible
> confusion with other usages then surely the same objection applies to
> SET.
>

true, it's nothing nice. There is only small set of short keyword

Zdenek Kotala's proposals is using

$name = value, ...
but I afraid so it could do some problems with prepared statements in future :(

Pavel


>                        regards, tom lane
>


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/11 Kevin Grittner <Kevin.Grittner@wicourts.gov>:
>>>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In any case, I'm not wedded to using AS for this, and am happy to
>> consider other suggestions.  But => isn't acceptable.
>
> How about using a bare equals sign (or the => characters) for
> parameter assignment, but require that the parameter name be prefixed
> with some special character?  (My first thought was a dollar sign, but
> that would cause problems in PL/pgSQL, so some other character would
> need to be used.)   It seems like that could give the parser enough
> context to consider the operator as parameter assignment, so it
> wouldn't require making it a fully reserved word or preclude other
> uses of the operator.

maybe this combination should be safe

$name => .... or $name -> ...

it's not used everywhere

Pavel

>
> I guess it would preclude the use of whatever character was chosen as
> a prefix operator in the context of a parameter list, however; which
> might be a fatal flaw to the idea.
>
> -Kevin
>


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
> maybe this combination should be safe
>
> $name => .... or $name -> ...
>
> it's not used everywhere

Why don't you actually just implement the whole thing first using a random, 
simple, and nonconflicting syntax?

Adjusting the syntax to something we can reach consensus on should be a change 
of about at most 10 lines at the end.


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/11 Peter Eisentraut <peter_e@gmx.net>:
> On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
>> maybe this combination should be safe
>>
>> $name => .... or $name -> ...
>>
>> it's not used everywhere
>
> Why don't you actually just implement the whole thing first using a random,
> simple, and nonconflicting syntax?
>
> Adjusting the syntax to something we can reach consensus on should be a change
> of about at most 10 lines at the end.
>

this is done

I did it today, so I have workable WIP prototype for ADA(Oracle)
syntax. Change of some syntax will not be really problem.

Pavel


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote:

>> what do you thing about?
>>
>> select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
>>
>> example
>> select dosome(10,20,30, SET flaga = true, flagb = false)
>
> I think AS read more naturally because you expect the parameter to  
> come
> first, not the SET keyword.

Coming to this a bit late, but it seems to me that, while it makes  
sense to assign a label to a value using "AS", it's kind of weird to  
use it to assign a value to a label.

SELECT foo( bar => 'ick', baz => 'ack' );
SELECT foo( bar AS 'ick', baz AS 'ack' );

As a Perl hacker, I'm strongly biased toward =>, but I guess AS isn't  
*too* bad. At least it's the same number of characters. Is -> right out?

Best,

David




Re: WIP: default values for function parameters

From
"Ian Caulfield"
Date:
2008/12/12 David E. Wheeler <david@kineticode.com>:
> On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote:
>
>>> what do you thing about?
>>>
>>> select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
>>>
>>> example
>>> select dosome(10,20,30, SET flaga = true, flagb = false)
>>
>> I think AS read more naturally because you expect the parameter to come
>> first, not the SET keyword.
>
> Coming to this a bit late, but it seems to me that, while it makes sense to
> assign a label to a value using "AS", it's kind of weird to use it to assign
> a value to a label.
>
> SELECT foo( bar => 'ick', baz => 'ack' );
> SELECT foo( bar AS 'ick', baz AS 'ack' );
>
> As a Perl hacker, I'm strongly biased toward =>, but I guess AS isn't *too*
> bad. At least it's the same number of characters. Is -> right out?
>

Personally I'm not keen on named parameter assignment, but if 'AS' is
unpopular, and '=>' et al conflict with operators, would verilog-style
syntax - eg function( .param(value) ) - be an idea?

Ian


Re: WIP: default values for function parameters

From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le 12 déc. 08 à 14:14, Ian Caulfield a écrit :
> unpopular, and '=>' et al conflict with operators, would verilog-style
> syntax - eg function( .param(value) ) - be an idea?

Ok, time to revisit the classics then ;)  http://www.gigamonkeys.com/book/functions.html#keyword-parameters

That would give us things like this:  SELECT foo(1, :name 'bar', :quantity 10);

As colon character does not appear in the list of allowed characters
for the CREATE OPERATOR, it seems it could be valid.  http://www.postgresql.org/docs/8.3/interactive/sql-
createoperator.html

Regards,
- --
dim


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklCaCMACgkQlBXRlnbh1blryQCfR9/6qtOlSAOiMbQ+RD8PRTi+
bsoAn2UiLMwZOG9nanXyMWfh5iAbQVTX
=p37W
-----END PGP SIGNATURE-----


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/12 Dimitri Fontaine <dfontaine@hi-media.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Le 12 déc. 08 à 14:14, Ian Caulfield a écrit :
>>
>> unpopular, and '=>' et al conflict with operators, would verilog-style
>> syntax - eg function( .param(value) ) - be an idea?
>
> Ok, time to revisit the classics then ;)
>  http://www.gigamonkeys.com/book/functions.html#keyword-parameters
>
> That would give us things like this:
>  SELECT foo(1, :name 'bar', :quantity 10);
>
> As colon character does not appear in the list of allowed characters for the
> CREATE OPERATOR, it seems it could be valid.
>  http://www.postgresql.org/docs/8.3/interactive/sql-createoperator.html
>

I dislike do LISP from nice PL :)

I thing so $name => is safe, but I didn't test it.

regards
Pavel

> Regards,
> - --
> dim
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iEYEARECAAYFAklCaCMACgkQlBXRlnbh1blryQCfR9/6qtOlSAOiMbQ+RD8PRTi+
> bsoAn2UiLMwZOG9nanXyMWfh5iAbQVTX
> =p37W
> -----END PGP SIGNATURE-----
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: WIP: default values for function parameters

From
Tom Lane
Date:
"David E. Wheeler" <david@kineticode.com> writes:
> As a Perl hacker, I'm strongly biased toward =>, but I guess AS isn't  
> *too* bad. At least it's the same number of characters. Is -> right out?

It's just as bad as => from the perspective of usurping a probable
user-defined operator name.

I think the fundamental problem with *any* notation like that is that
we don't have a concept of reserved words in the operator name space;
and without a precedent for it it's tough to justify suddenly breaking
people's code.  As was already noted, you could damp down the objections
by choosing some long and ugly operator name, but that's hardly going
to be pleasant to use.

So I think that really this is never going to fly unless it uses a
keyword-looking reserved word.  And we're not going to take some short
word that's not reserved now and suddenly make it so.  So, despite
Pavel's objection that the AS syntax proposal might be confused with
other uses of AS, I seriously doubt that any proposal is going to get
accepted that doesn't recycle AS or some other existing reserved word.
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 2:33 PM, Dimitri Fontaine wrote:

>
> Ok, time to revisit the classics then ;)
>  http://www.gigamonkeys.com/book/functions.html#keyword-parameters
>
> That would give us things like this:
>  SELECT foo(1, :name 'bar', :quantity 10);
>
> As colon character does not appear in the list of allowed characters  
> for the CREATE OPERATOR, it seems it could be valid.
>  http://www.postgresql.org/docs/8.3/interactive/sql- 
> createoperator.html

Oh, I like the colon, but better at the end of the label:
 SELECT foo(1, name: 'bar', quantity: 10);

Best,

Daivd


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:

> So I think that really this is never going to fly unless it uses a
> keyword-looking reserved word.  And we're not going to take some short
> word that's not reserved now and suddenly make it so.  So, despite
> Pavel's objection that the AS syntax proposal might be confused with
> other uses of AS, I seriously doubt that any proposal is going to get
> accepted that doesn't recycle AS or some other existing reserved word.

I'm okay with AS if that's the way it has to be, but what about a
colon right at the end of the label? A cast is two colons, so no
conflict there:
  SELECT foo(1, name: 'bar', quantity: 10);

No doubt I'm missing something…

Best

David

Re: WIP: default values for function parameters

From
Tom Lane
Date:
"David E. Wheeler" <david@kineticode.com> writes:
> I'm okay with AS if that's the way it has to be, but what about a  
> colon right at the end of the label?

Hmm ... a colon isn't considered to be an operator name, so this
wouldn't break any existing usage.  I'm a little bit worried about
what we might be cutting ourselves off from in the future, but
maybe it's a good solution.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/12 David E. Wheeler <david@kineticode.com>:
> On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:
>
>> So I think that really this is never going to fly unless it uses a
>> keyword-looking reserved word.  And we're not going to take some short
>> word that's not reserved now and suddenly make it so.  So, despite
>> Pavel's objection that the AS syntax proposal might be confused with
>> other uses of AS, I seriously doubt that any proposal is going to get
>> accepted that doesn't recycle AS or some other existing reserved word.

when I should exactly identify param name, the we should to use any symbols.

>
> I'm okay with AS if that's the way it has to be, but what about a colon
> right at the end of the label? A cast is two colons, so no conflict there:
>
>  SELECT foo(1, name: 'bar', quantity: 10);

it's look well, but I still prefer some combination with =

name: = ''
name: => '''
:name = ''
$name => ..
$name = ..

Maybe I am too conservative
Pavel

>
> No doubt I'm missing something…
>
> Best
>
> David

Re: WIP: default values for function parameters

From
"Rod Taylor"
Date:
How about IS or INTO?

param_name IS 3
param_name IS 'some string value'

3 INTO param_name
'some string value' INTO param_name




On Fri, Dec 12, 2008 at 8:47 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2008/12/12 David E. Wheeler <david@kineticode.com>:
>> On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:
>>
>>> So I think that really this is never going to fly unless it uses a
>>> keyword-looking reserved word.  And we're not going to take some short
>>> word that's not reserved now and suddenly make it so.  So, despite
>>> Pavel's objection that the AS syntax proposal might be confused with
>>> other uses of AS, I seriously doubt that any proposal is going to get
>>> accepted that doesn't recycle AS or some other existing reserved word.
>
> when I should exactly identify param name, the we should to use any symbols.
>
>>
>> I'm okay with AS if that's the way it has to be, but what about a colon
>> right at the end of the label? A cast is two colons, so no conflict there:
>>
>>  SELECT foo(1, name: 'bar', quantity: 10);
>
> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..
>
> Maybe I am too conservative
> Pavel
>
>>
>> No doubt I'm missing something…
>>
>> Best
>>
>> David
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Rod Taylor" <rod.taylor@gmail.com> writes:
> How about IS or INTO?

IS isn't a fully reserved word, and INTO seems pretty weird for this.

(IS is a type_func_name_keyword, so maybe we could make it work anyway,
but it sounds a bit fragile.)
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 2:47 PM, Pavel Stehule wrote:

> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..
>
> Maybe I am too conservative

Given that the colon already indicates "This label corresponds to that  
value", the other operator characters are redundant. In English, I  
write things like this:
 first: go to store second: get eggs

See what I mean? I quite like the colon solution.

Best,

David


Re: WIP: default values for function parameters

From
Sam Mason
Date:
On Fri, Dec 12, 2008 at 09:00:52AM -0500, Rod Taylor wrote:
> How about IS or INTO?
> 
> param_name IS 3
> param_name IS 'some string value'

that wouldn't work with NULL would it?  for example is:
 a IS NULL

checking if identifier 'a' IS NULL, or if you're giving NULL to
parameter 'a'.

> 3 INTO param_name
> 'some string value' INTO param_name

looks good.  Just to throw another item in, you could keep with SQL's
general verboseness and use:
 WITH ident = expr

that may be too much though.  Names that were mentioned in the keyword
file are:
 AS IS WITH ON HAVING INTO
and the following un-reserved entries MATCH NAME NAMES

 Sam


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
>> right at the end of the label? A cast is two colons, so no conflict there:
>>
>>  SELECT foo(1, name: 'bar', quantity: 10);
>
> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..

hmm :( $name isn't possible
:name is in conflict with vars in psql :(



>
> Maybe I am too conservative
> Pavel
>
>>
>> No doubt I'm missing something…
>>
>> Best
>>
>> David
>

Re: WIP: default values for function parameters

From
Tom Lane
Date:
I wrote:
> "Rod Taylor" <rod.taylor@gmail.com> writes:
>> How about IS or INTO?

> IS isn't a fully reserved word, and INTO seems pretty weird for this.

> (IS is a type_func_name_keyword, so maybe we could make it work anyway,
> but it sounds a bit fragile.)

Actually, there's an obvious counterexample for IS:
select func(foo IS NULL)

Two possible meanings...
        regards, tom lane


Re: WIP: default values for function parameters

From
Heikki Linnakangas
Date:
David E. Wheeler wrote:
> Coming to this a bit late, but it seems to me that, while it makes sense 
> to assign a label to a value using "AS", it's kind of weird to use it to 
> assign a value to a label.
> 
> SELECT foo( bar => 'ick', baz => 'ack' );
> SELECT foo( bar AS 'ick', baz AS 'ack' );

We could do it the other way round:

SELECT foo( 'ick' AS bar, 'ack' AS baz);

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: WIP: default values for function parameters

From
"Robert Haas"
Date:
> I'm okay with AS if that's the way it has to be, but what about a colon
> right at the end of the label? A cast is two colons, so no conflict there:
>
>  SELECT foo(1, name: 'bar', quantity: 10);
>
> No doubt I'm missing something…

I'd just like to mention that there are two different cases to
consider here.  One is when you want to pass some optional parameters,
but there are enough of them that it's inconvenient to have them in
some particular order.  This is the case I think you're primarily
catering to here.

The other is when you want the function that gets called to magically
know what name the system would have assigned to the column had the
expression been used in a select list, so that you can write things
xmlify(foo) and get <foo>...data from foo...</foo>.

I think the AS syntax makes a lot of sense for the second one, but not
so much for the first one.  Maybe we need both:

[keyword:] paramater_expression [AS label]

...Robert


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/12 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> David E. Wheeler wrote:
>>
>> Coming to this a bit late, but it seems to me that, while it makes sense
>> to assign a label to a value using "AS", it's kind of weird to use it to
>> assign a value to a label.
>>
>> SELECT foo( bar => 'ick', baz => 'ack' );
>> SELECT foo( bar AS 'ick', baz AS 'ack' );
>
> We could do it the other way round:
>
> SELECT foo( 'ick' AS bar, 'ack' AS baz);
>

I discussed about this form with Tom.

I thing so following should be readable:

name: [ optional => ] value
 SELECT foo( bar: 'ick', baz: 'ack' ); SELECT foo( bar: => 'ick', baz: => 'ack' );

or
 SELECT foo( bar: = 'ick', baz: = 'ack' );

reason for optional using of "=>" is too thin char ":", so =>
optically boost the colon.

Pavel



this is 100% compatible because syntax name: is new token

> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:

> I discussed about this form with Tom.
>
> I thing so following should be readable:
>
> name: [ optional => ] value
>
>  SELECT foo( bar: 'ick', baz: 'ack' );
>  SELECT foo( bar: => 'ick', baz: => 'ack' );
>
> or
>
>  SELECT foo( bar: = 'ick', baz: = 'ack' );
>
> reason for optional using of "=>" is too thin char ":", so =>
> optically boost the colon.

Hrm. I can see that, I guess. In that case, though, I think I'd prefer  
the colon at the beginning of the parameter label:
  SELECT foo( :bar => 'ick', :baz => 'ack' );

In that case, though, I'd want the => to be required. Note that  
there's a precedent here, too: This is Ruby's syntax for using  
"symbols" for parameter names.

> this is 100% compatible because syntax name: is new token

Interesting. I hadn't expected that the use of the colon to make the  
use of => be okay. Cool that it does, though.

Best,

David


Re: WIP: default values for function parameters

From
Gregory Stark
Date:
"Pavel Stehule" <pavel.stehule@gmail.com> writes:

> 2008/12/12 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
>
>> We could do it the other way round:
>>
>> SELECT foo( 'ick' AS bar, 'ack' AS baz);

I always assumed we were talking about it this way. Everywhere else in SQL AS
is followed by the labels, not the values.

> I discussed about this form with Tom.
>
> I thing so following should be readable:
>
> name: [ optional => ] value
>
>   SELECT foo( bar: 'ick', baz: 'ack' );
>   SELECT foo( bar: => 'ick', baz: => 'ack' );
>
> or
>
>   SELECT foo( bar: = 'ick', baz: = 'ack' );
>
> reason for optional using of "=>" is too thin char ":", so =>
> optically boost the colon.

These don't solve anything. There's nothing stopping you from defining a unary
prefix operator => or =

In any case this is all weird. SQL isn't C and doesn't have random bits of
punctuation involved in syntax. It uses whole words for just about everything.
Anything you do using punctuation characters is going to look out of place.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/12 David E. Wheeler <david@kineticode.com>:
> On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:
>
>> I discussed about this form with Tom.
>>
>> I thing so following should be readable:
>>
>> name: [ optional => ] value
>>
>>  SELECT foo( bar: 'ick', baz: 'ack' );
>>  SELECT foo( bar: => 'ick', baz: => 'ack' );
>>
>> or
>>
>>  SELECT foo( bar: = 'ick', baz: = 'ack' );
>>
>> reason for optional using of "=>" is too thin char ":", so =>
>> optically boost the colon.
>
> Hrm. I can see that, I guess. In that case, though, I think I'd prefer the
> colon at the beginning of the parameter label:
>
>  SELECT foo( :bar => 'ick', :baz => 'ack' );

this syntax is used yet
http://www.postgresql.org/docs/8.3/interactive/app-psql.html

testdb=> \set foo 'my_table'
testdb=> SELECT * FROM :foo;

would then query the table my_table. The value of the variable is
copied literally, so it can even contain unbalanced quotes or
backslash commands. You must make sure that it makes sense where you
put it. Variable interpolation will not be performed into quoted SQL
entities.

A popular application of this facility is to refer to the last
inserted OID in subsequent statements to build a foreign key scenario.
Another possible use of this mechanism is to copy the contents of a
file into a table column. First load the file into a variable and then
proceed as above:

testdb=> \set content '''' `cat my_file.txt` ''''
testdb=> INSERT INTO my_table VALUES (:content);

regards
Pavel Stehule




>
> In that case, though, I'd want the => to be required. Note that there's a
> precedent here, too: This is Ruby's syntax for using "symbols" for parameter
> names.
>
>> this is 100% compatible because syntax name: is new token
>
> Interesting. I hadn't expected that the use of the colon to make the use of
> => be okay. Cool that it does, though.
>
> Best,
>
> David
>


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 3:57 PM, Gregory Stark wrote:

> In any case this is all weird. SQL isn't C and doesn't have random  
> bits of
> punctuation involved in syntax. It uses whole words for just about  
> everything.
> Anything you do using punctuation characters is going to look out of  
> place.

Well, what do databases other than Oracle (which uses =>) do? What's  
likely to end up in the standard?

Best,

David


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 3:56 PM, Pavel Stehule wrote:

>> Hrm. I can see that, I guess. In that case, though, I think I'd  
>> prefer the
>> colon at the beginning of the parameter label:
>>
>> SELECT foo( :bar => 'ick', :baz => 'ack' );
>
> this syntax is used yet
> http://www.postgresql.org/docs/8.3/interactive/app-psql.html
>
> testdb=> \set foo 'my_table'
> testdb=> SELECT * FROM :foo;

Oh, right. Damn.

In that case, I'm happy with your proposal of
  name: [ => ] value

Where => is optional.

Or, if that just doesn't fly for reasons such as those cited by Greg  
Stark, AS would seem to be the only choice left. Though what's on the  
lhs vs the rhs is debatable:
  SELECT foo( label AS 'value' );  SELECT foo( 'value' AS label );

Maybe they're reversible?

Best,

David


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"David E. Wheeler" <david@kineticode.com> writes:
> Hrm. I can see that, I guess. In that case, though, I think I'd prefer  
> the colon at the beginning of the parameter label:

>    SELECT foo( :bar => 'ick', :baz => 'ack' );

That's ugly, and incompatible with ecpg syntax, and what's the redeeming
value anyway?

In any case, whichever side you put the colon on, Pavel's proposal for
adding => to it is a nonstarter --- he's ignoring the possibility that
=> is defined as a prefix operator.

Hmm ... actually, ecpg might be a problem here anyway.  I know it has
special meaning for :name, but does it allow space between the colon
and the name?  If it does then the colon syntax loses.  If it doesn't
then you could do "name: value" as long as you were careful to leave
a space after the colon.
        regards, tom lane


Re: WIP: default values for function parameters

From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 12 déc. 08 à 15:57, Gregory Stark a écrit :
> These don't solve anything. There's nothing stopping you from
> defining a unary
> prefix operator => or =

That's why I'm preferring the common-lisp syntax of :param value, or
its variant param: value.

> In any case this is all weird. SQL isn't C and doesn't have random
> bits of
> punctuation involved in syntax. It uses whole words for just about
> everything.
> Anything you do using punctuation characters is going to look out of
> place.

Well, with the exception of function argument list, beginning with
( and ending with ) and where parameters are separated by ,. Maybe
some : in there would shock users.
  SELECT foo(a, b, c);  SELECT foo(a, :c 5);  SELECT foo(a, c: 5);

Not so much new punctuation characters there, 1 out of 4.
- --
dim




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklCfysACgkQlBXRlnbh1blWJQCfdLCB0B9xOzvfX2tOfoBL4cxo
X4UAoI3aTK+834Cx5Wbly/snj2hQbQTX
=s6w5
-----END PGP SIGNATURE-----


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> We could do it the other way round:
> SELECT foo( 'ick' AS bar, 'ack' AS baz);

Yeah, that's the direction I had always assumed that we would use,
if AS is the chosen syntax for this.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Greg Stark"
Date:
On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> That's why I'm preferring the common-lisp syntax of :param value, or its
> variant param: value.

FWIW there is no such common-lisp syntax. Colon is just a regular
symbol character and :param is just a regular symbol in common-lisp.
There is a convention that functions parse their argument lists
looking for such tokens as indicators of what to do with the next
argument but it's purely a convention. There's no syntactic
significance to the colon.

A similar problem arises with using Perl as a precedent. => is just a
regular operator in perl which quotes the lhs as a string if it's a
simple token and otherwise behaves just like a comma. That would be
very different from what we're talking about having it do here.

-- 
greg


Re: WIP: default values for function parameters

From
"Douglas McNaught"
Date:
On Fri, Dec 12, 2008 at 10:31 AM, Greg Stark <stark@enterprisedb.com> wrote:
> On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
> <dfontaine@hi-media.com> wrote:
>> That's why I'm preferring the common-lisp syntax of :param value, or its
>> variant param: value.
>
> FWIW there is no such common-lisp syntax. Colon is just a regular
> symbol character and :param is just a regular symbol in common-lisp.
> There is a convention that functions parse their argument lists
> looking for such tokens as indicators of what to do with the next
> argument but it's purely a convention. There's no syntactic
> significance to the colon.

Drifting off-topic and being really nit-picky, you're wrong.  :)  It's
more than just a "convention".  Colons *are* special in symbol
names--the leading colon designates the symbol as being in the KEYWORD
package (i.e. symbol namespace; you can put symbols in other packages
by prepending a package name to the colon) and there is standard
syntax (&key) for specifying allowed keyword arguments to a function;
said keys must be symbols in the KEYWORD package.

So the proposed foo( :bar 12, :baz 'stuff' ) syntax is actually very
close to the Common Lisp syntax, though there may be very good reasons
not to use it in PG.

> A similar problem arises with using Perl as a precedent. => is just a
> regular operator in perl which quotes the lhs as a string if it's a
> simple token and otherwise behaves just like a comma. That would be
> very different from what we're talking about having it do here.

Very true, and I think the "don't break people who are using => as a
prefix operator" argument is pretty conclusive.

-Doug


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 4:06 PM, Tom Lane wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> Hrm. I can see that, I guess. In that case, though, I think I'd  
>> prefer
>> the colon at the beginning of the parameter label:
>
>>   SELECT foo( :bar => 'ick', :baz => 'ack' );
>
> That's ugly, and incompatible with ecpg syntax, and what's the  
> redeeming
> value anyway?

Beauty is in the eye of the beholder, I guess. I got used to it  
hacking Ruby last year.

> In any case, whichever side you put the colon on, Pavel's proposal for
> adding => to it is a nonstarter --- he's ignoring the possibility that
> => is defined as a prefix operator.

Ah.

> Hmm ... actually, ecpg might be a problem here anyway.  I know it has
> special meaning for :name, but does it allow space between the colon
> and the name?  If it does then the colon syntax loses.  If it doesn't
> then you could do "name: value" as long as you were careful to leave
> a space after the colon.

So would that eliminate
  SELECT foo( bar: 'ick', baz: 'ack' );

as a possibility?

Best,

David



Re: WIP: default values for function parameters

From
Michael Meskes
Date:
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
> Hmm ... actually, ecpg might be a problem here anyway.  I know it has
> special meaning for :name, but does it allow space between the colon
> and the name?  If it does then the colon syntax loses.  If it doesn't

No. Here's the lexer rule:

<SQL>:{identifier}((("->"|\.){identifier})|(\[{array}\]))*  

No space possible between ":"  and {identifier}.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Michael Meskes <meskes@postgresql.org> writes:
> On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
>> Hmm ... actually, ecpg might be a problem here anyway.  I know it has
>> special meaning for :name, but does it allow space between the colon
>> and the name?  If it does then the colon syntax loses.  If it doesn't

> No. Here's the lexer rule:
> <SQL>:{identifier}((("->"|\.){identifier})|(\[{array}\]))*  
> No space possible between ":"  and {identifier}.

Excellent.  I checked that psql's colon-variable feature behaves the
same.  So it looks like the proposed "name: value" syntax would indeed
not break any existing features.  Barring better ideas I think we should
go with that one.
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 12, 2008, at 7:05 PM, Tom Lane wrote:

> Excellent.  I checked that psql's colon-variable feature behaves the
> same.  So it looks like the proposed "name: value" syntax would indeed
> not break any existing features.  Barring better ideas I think we  
> should
> go with that one.

+1

Best,

David



Re: WIP: default values for function parameters

From
Andrew Dunstan
Date:

Tom Lane wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>   
>> On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
>>     
>>> Hmm ... actually, ecpg might be a problem here anyway.  I know it has
>>> special meaning for :name, but does it allow space between the colon
>>> and the name?  If it does then the colon syntax loses.  If it doesn't
>>>       
>
>   
>> No. Here's the lexer rule:
>> <SQL>:{identifier}((("->"|\.){identifier})|(\[{array}\]))*  
>> No space possible between ":"  and {identifier}.
>>     
>
> Excellent.  I checked that psql's colon-variable feature behaves the
> same.  So it looks like the proposed "name: value" syntax would indeed
> not break any existing features.  Barring better ideas I think we should
> go with that one.
>
>             
>   

Does that mean the whitespace following the : will be required? (I could 
figure it out but brain is otherwise occupied).

cheers

andrew


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
>> Excellent.  I checked that psql's colon-variable feature behaves the
>> same.  So it looks like the proposed "name: value" syntax would indeed
>> not break any existing features.  Barring better ideas I think we should
>> go with that one.

> Does that mean the whitespace following the : will be required? (I could 
> figure it out but brain is otherwise occupied).

Only if what's immediately after the colon is an identifier, and
possibly not even then depending on the client-side context.  For
instance psql won't do anything unless the identifier matches one
of its variables.  We'd definitely want to document a recommendation
to leave a space there, though.
        regards, tom lane


Re: WIP: default values for function parameters

From
"Asko Oja"
Date:


On Fri, Dec 12, 2008 at 8:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Meskes <meskes@postgresql.org> writes:
> On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
>> Hmm ... actually, ecpg might be a problem here anyway.  I know it has
>> special meaning for :name, but does it allow space between the colon
>> and the name?  If it does then the colon syntax loses.  If it doesn't

> No. Here's the lexer rule:
> <SQL>:{identifier}((("->"|\.){identifier})|(\[{array}\]))*
> No space possible between ":"  and {identifier}.

Excellent.  I checked that psql's colon-variable feature behaves the
same.  So it looks like the proposed "name: value" syntax would indeed
not break any existing features.  Barring better ideas I think we should
go with that one. 
+1
"name: value" should be good enough

                       regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> Excellent.  I checked that psql's colon-variable feature behaves the
> same.  So it looks like the proposed "name: value" syntax would indeed
> not break any existing features.  Barring better ideas I think we should
> go with that one.

I personally thought that AS was a better idea.


Re: WIP: default values for function parameters

From
Albert Cervera i Areny
Date:
A Dissabte 13 Desembre 2008, Peter Eisentraut va escriure:
> On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> > Excellent.  I checked that psql's colon-variable feature behaves the
> > same.  So it looks like the proposed "name: value" syntax would indeed
> > not break any existing features.  Barring better ideas I think we should
> > go with that one.
>
> I personally thought that AS was a better idea.

+1

-- 
Albert Cervera i Areny
http://www.NaN-tic.com


Re: WIP: default values for function parameters

From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit :
> On Friday 12 December 2008 20:05:57 Tom Lane wrote:
>> Excellent.  I checked that psql's colon-variable feature behaves the
>> same.  So it looks like the proposed "name: value" syntax would
>> indeed
>> not break any existing features.  Barring better ideas I think we
>> should
>> go with that one.
>
> I personally thought that AS was a better idea.

It seems some people want to be able to overload some default
parameters (but not others) and at the same time alias them to some
new label. I'm not sure I understand it all, but it seems an example
of it would be like:  SELECT xml_function(a, b: 'foo' AS bar);

If this is what some people want when all the spare parts are bound
together, we don't have the option to use AS for both the meanings.

Regards,
- --
dim



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklDqg0ACgkQlBXRlnbh1blPKwCfayDs3vFnswOYe7yLRyEaJf00
HvYAn1sfYndeKfI4ac09IxuxUVuUqbdX
=BGDG
-----END PGP SIGNATURE-----


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Le 13 d�c. 08 � 11:39, Peter Eisentraut a �crit :
>> I personally thought that AS was a better idea.

> It seems some people want to be able to overload some default  
> parameters (but not others) and at the same time alias them to some  
> new label. I'm not sure I understand it all, but it seems an example  
> of it would be like:
>    SELECT xml_function(a, b: 'foo' AS bar);

> If this is what some people want when all the spare parts are bound  
> together, we don't have the option to use AS for both the meanings.

I personally agree that AS seems more SQL-ish, but that's in the eye
of the beholder.

The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT
doesn't (and won't) have named parameters.  But it is true that
XMLELEMENT is doing something subtly different with the AS clause than
what a named parameter would do; so you could argue that there's a
potential for user confusion there.

However, after looking at the precedent of XMLELEMENT, it's hard to deny
that if the SQL committee ever chose to standardize named parameters,
AS is what they would use.  The chances that ":" would become the
standard are negligible --- that's not the sort of syntax they like
to standardize.
        regards, tom lane


Re: WIP: default values for function parameters

From
Bruce Momjian
Date:
Dimitri Fontaine wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Le 13 d�c. 08 � 11:39, Peter Eisentraut a �crit :
> > On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> >> Excellent.  I checked that psql's colon-variable feature behaves the
> >> same.  So it looks like the proposed "name: value" syntax would  
> >> indeed
> >> not break any existing features.  Barring better ideas I think we  
> >> should
> >> go with that one.
> >
> > I personally thought that AS was a better idea.
> 
> It seems some people want to be able to overload some default  
> parameters (but not others) and at the same time alias them to some  
> new label. I'm not sure I understand it all, but it seems an example  
> of it would be like:
>    SELECT xml_function(a, b: 'foo' AS bar);
> 
> If this is what some people want when all the spare parts are bound  
> together, we don't have the option to use AS for both the meanings.

I agree "AS" is better.  And why would the "AS" above be inside the
parentheses;  I assume it would be:
   SELECT xml_function(a, b: 'foo') AS bar;

Giving labels to parameters passed into functions makes no sense.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:

> However, after looking at the precedent of XMLELEMENT, it's hard to  
> deny
> that if the SQL committee ever chose to standardize named parameters,
> AS is what they would use.  The chances that ":" would become the
> standard are negligible --- that's not the sort of syntax they like
> to standardize.

Any chance that both "AS" and ":" could be supported, so that it's at  
the discretion of the user?

Best,

David


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"David E. Wheeler" <david@kineticode.com> writes:
> On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:
>> However, after looking at the precedent of XMLELEMENT, it's hard to  
>> deny that if the SQL committee ever chose to standardize named parameters,
>> AS is what they would use.  The chances that ":" would become the
>> standard are negligible --- that's not the sort of syntax they like
>> to standardize.

> Any chance that both "AS" and ":" could be supported, so that it's at  
> the discretion of the user?

I'm sure it's technically possible, but I see no redeeming social value
in it ... we should pick one and quit repainting the bike shed.
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:

> I'm sure it's technically possible, but I see no redeeming social
> value
> in it ... we should pick one and quit repainting the bike shed.

Well, as I've said, I'm okay with AS, though it's not my favorite. I
can see the argument that it's more likely to eventually make it into
the SQL standard. I don't suppose that the position of the label and
the value on either side of "AS" could be reversible, could it?
  SELECT foo( bar AS 'ick', 6 AS baz );

Probably not, I'm thinking…

Best,

David

Re: WIP: default values for function parameters

From
Tom Lane
Date:
"David E. Wheeler" <david@kineticode.com> writes:
> I don't suppose that the position of the label and  
> the value on either side of "AS" could be reversible, could it?

No.  Consider
SELECT foo(bar AS baz) FROM ...

If the from-clause provides columns named both bar and baz, it would
be impossible to decide what is meant.
        regards, tom lane


Re: WIP: default values for function parameters

From
Bruce Momjian
Date:
David E. Wheeler wrote:
> On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:
> 
> > I'm sure it's technically possible, but I see no redeeming social  
> > value
> > in it ... we should pick one and quit repainting the bike shed.
> 
> Well, as I've said, I'm okay with AS, though it's not my favorite. I  
> can see the argument that it's more likely to eventually make it into  
> the SQL standard. I don't suppose that the position of the label and  
> the value on either side of "AS" could be reversible, could it?
> 
>    SELECT foo( bar AS 'ick', 6 AS baz );
> 
> Probably not, I'm thinking?

Yea, probably not.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: WIP: default values for function parameters

From
Grzegorz Jaskiewicz
Date:
On 2008-12-13, at 16:19, Tom Lane wrote:
>>
>
> I'm sure it's technically possible, but I see no redeeming social  
> value
> in it ... we should pick one and quit repainting the bike shed.

+1000



Re: WIP: default values for function parameters

From
"Robert Haas"
Date:
> I personally agree that AS seems more SQL-ish, but that's in the eye
> of the beholder.
>
> The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT
> doesn't (and won't) have named parameters.  But it is true that
> XMLELEMENT is doing something subtly different with the AS clause than
> what a named parameter would do; so you could argue that there's a
> potential for user confusion there.

It's not ambiguous unless for some reason you wanted to support doing
both of those things at the same time, but I'm having a hard time
coming up with a realistic use case for that.  Still, I think we
probably do want to at least leave the door open to do both things at
different times.  For the XMLELEMENT-type case, "value AS label" seems
far superior to "label: value", so if you're going to pick one syntax
for both things, it should be that one.

Alternatively, using "label: value" for identifying which parameter is
intended to get the value and "value AS label" for relabelling seems
OK too, though your argument about standards-compliance is a valid
one.

...Robert


Re: WIP: default values for function parameters

From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 13 déc. 08 à 17:05, Tom Lane a écrit :
> I personally agree that AS seems more SQL-ish, but that's in the eye
> of the beholder.

So do I, but I fear it's already taken for another meaning.

> The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT
> doesn't (and won't) have named parameters.

My concern is the other way around. This function provides support for
arguments relabeling, but reading some other threads here I think we
don't yet support this feature for user defined function. Or maybe
only for C-language user defined functions.

What if relabeling support were to spread some more?
My point is that we couldn't offer generalization of an existing
feature if we reuse AS for default parameter value. Or the user would
have to choose between having more than one argument with a default
value and relabeling support. That would be awkward.

No it could very well be that the point does not exists, but someone
would have to explain why to me, cause I'm sure not getting it by
myself...

Regards,
- --
dim



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklEJyEACgkQlBXRlnbh1bmlgwCfW8PPDh1rIH6Fk/3oEQ0t1+TH
vDYAni0kE4us/AvWuI6HTyaywAgP9Tga
=jB1l
-----END PGP SIGNATURE-----


Re: WIP: default values for function parameters

From
Tom Lane
Date:
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> What if relabeling support were to spread some more?

Spread to what?  AFAICS the way that XMLELEMENT uses AS is a
single-purpose wart (much like a lot of other stuff the SQL committee
invents :-().  I do not see a need to reserve AS in function argument
lists for that purpose.  In any case, the proposed meaning here is only
relevant to functions that expose names for their parameters; so in
principle you could still do something like what XMLELEMENT does for any
function that does not create names for its parameters.
        regards, tom lane


Re: WIP: default values for function parameters

From
Dimitri Fontaine
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 13 déc. 08 à 22:32, Tom Lane a écrit :
> Spread to what?  AFAICS the way that XMLELEMENT uses AS is a
> single-purpose wart

Ok now that explains.
The common lisp inspired syntax is only nice if we're to avoid using
AS, which I thought was the situation. Sorry for some more confusion
here.

Regards,
- --
dim




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklEK6sACgkQlBXRlnbh1blNKACgmwZSY1ZpKBhK/SxhPdjZ1F6q
mtcAn3OaNs1jIQOymz/6ex/ghlO+avcO
=dGhM
-----END PGP SIGNATURE-----


Re: WIP: default values for function parameters

From
"Robert Haas"
Date:
> What if relabeling support were to spread some more?

The only example I can think of besides XML is JSON.  There might be a
few more.  Basically, relabelling is a handy shortcut when you are
serializing data and want to avoid specifying a list of columns and an
(almost) identical list of labels.  Otherwise, it's not good for much.I think we should eventually aim to support
user-definedfunctions
 
that work like this, because people will forever be inventing new ways
to serialize things and it'd be nice not to have to recompile to add
support for a new one.

I suppose you might want to do something like this:

html_input(foo) returns <input name='foo' type='text' value='[...value
of foo...]'>
html_input(foo AS bar) returns <input name='foo' type='text'
value='[...value of foo...]'>
html_input(foo, type: hidden) returns <input name='foo' type='hidden'
value='[...value of foo...]'>

...Robert


Re: WIP: default values for function parameters

From
"Greg Stark"
Date:
On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> What if relabeling support were to spread some more?
>
> The only example I can think of besides XML is JSON.  There might be a
> few more.  Basically, relabelling is a handy shortcut when you are
> serializing data and want to avoid specifying a list of columns and an
> (almost) identical list of labels.

The whole relabeling thing seems like a seriously silly idea. Why is
it at all a shortcut to use "AS" instead of "," ? The relabeling adds
zero actual expressiveness, it just makes a fancy way to pass an
argument.





-- 
greg


Re: WIP: default values for function parameters

From
"Robert Haas"
Date:
> The whole relabeling thing seems like a seriously silly idea. Why is
> it at all a shortcut to use "AS" instead of "," ?

Because a lot of times you don't want to relabel, so you omit the "AS
label" part altogether, and the label is deduced from the expression
itself.  For example, I don't need to write:

SELECT json(r.foo AS foo, r.bar AS bar, r.baz AS baz, r.bletch AS
quux) FROM rel r;

I can just write:

SELECT json(r.foo, r.bar, r.baz, r.bletch AS quux) FROM rel r;

...which is a a lot more compact when the number of arguments is large.

...Robert


Re: WIP: default values for function parameters

From
Tom Lane
Date:
"Greg Stark" <stark@enterprisedb.com> writes:
> On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> What if relabeling support were to spread some more?
>> 
>> The only example I can think of besides XML is JSON.  There might be a
>> few more.  Basically, relabelling is a handy shortcut when you are
>> serializing data and want to avoid specifying a list of columns and an
>> (almost) identical list of labels.

> The whole relabeling thing seems like a seriously silly idea.

I wouldn't say that it's silly.  What I do say is that it makes no sense
to imagine that it would be used at the same time as named parameters.
The entire point of something like XMLELEMENT is that it takes a list of
undifferentiated parameters, which therefore do not need to have names
so far as the function is concerned.
        regards, tom lane


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 14, 2008, at 6:55 AM, Tom Lane wrote:

>> The whole relabeling thing seems like a seriously silly idea.
>
> I wouldn't say that it's silly.  What I do say is that it makes no  
> sense
> to imagine that it would be used at the same time as named parameters.
> The entire point of something like XMLELEMENT is that it takes a  
> list of
> undifferentiated parameters, which therefore do not need to have names
> so far as the function is concerned.

Perhaps not, but I have to say, looking at Robert's JSON example:

> SELECT json(r.foo AS foo, r.bar AS bar, r.baz AS baz, r.bletch AS
> quux) FROM rel r;

I would be pretty confused. It looks exactly like the proposed syntax  
for named parameters. So while syntactically they may never be used  
together, there's a semantic mismatch, IMHO.

Best,

David


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/14 Greg Stark <stark@enterprisedb.com>:
> On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> What if relabeling support were to spread some more?
>>
>> The only example I can think of besides XML is JSON.  There might be a
>> few more.  Basically, relabelling is a handy shortcut when you are
>> serializing data and want to avoid specifying a list of columns and an
>> (almost) identical list of labels.
>
> The whole relabeling thing seems like a seriously silly idea. Why is
> it at all a shortcut to use "AS" instead of "," ? The relabeling adds
> zero actual expressiveness, it just makes a fancy way to pass an
> argument.
>
>

Because AS is signal for collecting column (or label) names.

I thing so we should use "AS" as Tom's proposal, together with SQL/XML
functionality.

It's only idea: default behave is using as for param name specification,

seconf with flag maybe labeled allows using AS in SQL/XML behave

But this syntax don't allow use this feature together (it is maybe enought).\

create function json(variadic labeled values int[]) ...

Pavel


Re: WIP: default values for function parameters

From
Zeugswetter Andreas OSB sIT
Date:
> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..

I wonder about name := ''.

:= is used in Pascal/Ada to assign a value. Or would that again be an allowed operator in pg ?

Andreas

Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/15 Zeugswetter Andreas OSB sIT <Andreas.Zeugswetter@s-itsolutions.at>:
>
>> it's look well, but I still prefer some combination with =
>>
>> name: = ''
>> name: => '''
>> :name = ''
>> $name => ..
>> $name = ..
>
> I wonder about name := ''.
>
> := is used in Pascal/Ada to assign a value. Or would that again be an allowed operator in pg ?
>

I like it too, but there is problem with possible collision with
custom operator

Pavel

> Andreas


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
David E. Wheeler wrote:
> Perhaps not, but I have to say, looking at Robert's JSON example:
> 
>> SELECT json(r.foo AS foo, r.bar AS bar, r.baz AS baz, r.bletch AS
>> quux) FROM rel r;
> 
> I would be pretty confused. It looks exactly like the proposed syntax 
> for named parameters. So while syntactically they may never be used 
> together, there's a semantic mismatch, IMHO.

In my mind, you just have to think about it hard enough to come to 
realize that, when viewed from the right angle, the semantic conflict 
might not exist after all.  It's a bit tricky, but I think it's possible.


Re: WIP: default values for function parameters

From
Peter Eisentraut
Date:
Pavel Stehule wrote:
> Because AS is signal for collecting column (or label) names.
> 
> I thing so we should use "AS" as Tom's proposal, together with SQL/XML
> functionality.

Yes, please implement that.

> It's only idea: default behave is using as for param name specification,
> 
> seconf with flag maybe labeled allows using AS in SQL/XML behave
> 
> But this syntax don't allow use this feature together (it is maybe enought).\
> 
> create function json(variadic labeled values int[]) ...

I didn't get that ... :-(


Re: WIP: default values for function parameters

From
"Pavel Stehule"
Date:
2008/12/15 Peter Eisentraut <peter_e@gmx.net>:
> Pavel Stehule wrote:
>>
>> Because AS is signal for collecting column (or label) names.
>>
>> I thing so we should use "AS" as Tom's proposal, together with SQL/XML
>> functionality.
>
> Yes, please implement that.
>

I'll do it - it's better then nothing,

>> It's only idea: default behave is using as for param name specification,
>>
>> seconf with flag maybe labeled allows using AS in SQL/XML behave
>>
>> But this syntax don't allow use this feature together (it is maybe
>> enought).\
>>
>> create function json(variadic labeled values int[]) ...
>
> I didn't get that ... :-(

First I have to look to code, use "AS" means, so there will be one
syntactic role with two meanings.

Pavel
>


Re: WIP: default values for function parameters

From
"David E. Wheeler"
Date:
On Dec 15, 2008, at 11:05 AM, Peter Eisentraut wrote:

> In my mind, you just have to think about it hard enough to come to  
> realize that, when viewed from the right angle, the semantic  
> conflict might not exist after all.  It's a bit tricky, but I think  
> it's possible.

Better for users not to have to think about it, IMHO. Still, they  
will, in the future, more likely be familiar with passing parameters  
to functions than with the XML stuff, and so won't have to worry about  
it until they use the XML stuff.

Best,

David