Re: default parameters for built-in functions (was Re: Documentation Update: Document pg_start_backup checkpoint behavior)

2009/4/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> I wrote:
>> Bruce suggested what seemed like an excellent idea, which is to make
>> this self-documenting using the new default-arguments feature ---
>> it'll look something like this in \df:
>
>>                              List of functions
>>  Schema | Name | Result data type |          Argument data types
>> --------+------+------------------+----------------------------------------
>>  public | foo  | integer          | label text, fast boolean DEFAULT false
>
> On poking into this, it's a bit uglier to do than I first thought.
> pg_proc.proargdefaults has to be the text representation of an
> expression tree.  This means that to do it directly in pg_proc.h
> would take writing something like
>
> ({CONST :consttype 16 :consttypmod -1 :constlen 1 :constbyval true :constisnull false :location -1 :constvalue 1 [ 0 0 0 0 ]})
>
> Ugly as that is, it gets worse fast: the constvalue representation is
> machine-dependent, both as to width and endianness.  And maintaining
> such things in the face of expression tree changes would be no fun
> either.
>
> So I think that's out.  The only alternative that comes to mind is
> to have initdb issue an additional SQL command to establish the default
> after the bootstrap phase; that is, something like
>
> CREATE OR REPLACE FUNCTION
>  pg_start_backup(label text, fast boolean DEFAULT false)
>  RETURNS text LANGUAGE internal STRICT AS 'start_backup';
>
> in system_views.sql or some such place.
>
> Or we could just not bother with using a default here (ie, go back to
> declaring two pg_proc entries).  It's not buying us all that much.
>
> Comments?
>

I like this idea - it should help for some spec types too

regards
Pavel

>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>