Re: WIP: default values for function parameters

2008/12/12 David E. Wheeler <david(at)kineticode(dot)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
>