2010/8/6 Tom Lane <t...@sss.pgh.pa.us>:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
>> For Tom: proposed syntax can be used generally - everywhere when you
>> are working with collection. It can be used for hash (hstore)
>> constructor for example. For me is more readable code like
>
>> select hstore(name := 'Tomas', surname := 'Novak')
>
> You've tried to sell us on that before, with few takers. This proposed
> use-case impresses me even less than the previous ones, because callers
> of xslt_process seem quite likely to need to work with non-constant
> parameter names.
>
> In any case, given what we have at the moment for function overload
> resolution rules, I think it's a fundamentally bad idea to introduce
> a "wild card" function type that would necessarily conflict with
> practically every other possible function declaration. So regardless
> of what use-cases you propose, I'm going to vote against that.
It must not be a function. Just I missing any tool that helps with
complex structured data. This proposed kind functions has one
advantage - there isn't necessary any change in parser. Yes, I can use
a pair of arrays, I can use a one array with seq name, value, I can
use a custom parser. But nothing from these offers a comfort or
readability for example a Perl's hash tables.
so if we have a integrated hash tables, then we can to write some like
CREATE FUNCTION xslt_process(..,.., text{})
select xslt_process(..,.., { par1 => val1, par2 => val3, .. } )
any simple method can significantly help for us, who write a lot of
complex stored procedures. It can be a big help. I am only
dissatisfied because it is "Perlism" - maybe I don't understand SQL
well, but my personal opinion about the most natural syntax for this
situation is some like SQL/XML - xmlattributes or named notation. SQL
isn't too much consistent too - it uses two semantically similar
syntax
foo(name=>value, ..) versus foo(value AS name, ..)
Next my idea was mix of named parameters and marked variadic parameter:
CREATE FUNCTION xslt_process(..,.., VARIADIC LABELED text[])
and then we can call SELECT xslt_process(..,.., par1 := var, ..)
This doesn't introduce a heavy new syntax - just use old in some
specific context. It is only my feeling, so this way is more SQL
natural than using a some hash data type. Maybe you don't think, so
stored procedures must not to have a this functionality. Everywhere
where you can to wrap a c library for SQL you have to meet this task -
often you have to pass a set of flags, collection of values. With
default parameter values situation is better then before, but its
still not ideal - for example SOAP interface or dblink to Oracle
SELECT exec(db, 'SELECT * FROM foo where c = :name', name => 'Pavel')
so this is my motivation - the possibility to write generic custom
functions. Sure - this is "redundant" to existing functionality. I can
write:
SELECT exec(db, 'SELECT * FROM ...', ARRAY['name'], ARRAY['Pavel']) --
Robert'syntax
or your syntax:
SELECT exec(db, 'SELECT * FROM ...', ARRAY['name','Pavel']) or
like current xml2 syntax:
SELECT exec(db, 'SELECT * FROM ...', 'name="Pavel")
But these versions are "too simple" if you understand me. It doesn't
do life of SQL stored procedure's programmer simper.
Regards
Pavel
p.s. sorry for offtopic
p.s. for me isn't important notation. Just I would to like more things
with custom functions withou parser modification.
>
> 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
