Re: WIP: default values for function parameters - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: WIP: default values for function parameters
Date
Msg-id 162867790812091131h56a9b7a1r8ca30a3e19295ea9@mail.gmail.com
Whole thread Raw
In response to Re: WIP: default values for function parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
>


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: parallel restore vs. windows
Next
From: "Alex Hunsaker"
Date:
Subject: Re: contrib/pg_stat_statements 1202