| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
| Subject: | Re: WIP: default values for function parameters |
| Date: | 2008-11-25 01:20:58 |
| Message-ID: | 8431.1227576058@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2008-11-25 01:42:13 | Re: blatantly a bug in the documentation |
| Previous Message | Emmanuel Cecchet | 2008-11-24 23:23:43 | Re: Transactions and temp tables |