Skip site navigation (1) Skip section navigation (2)

Re: variadic function support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: variadic function support
Date: 2008-06-24 00:59:17
Message-ID: 5827.1214269157@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> What would you consider "proper and full support"?
>
> I don't know. But this doesn't feel like it. 

That's a fairly weak argument for rejecting a patch that provides a
feature many people have asked for.

I thought the patch was pretty clever, actually.  The main functionality
complaint someone might level against it is that all the variadic
arguments have to be (coercible to) the same type.  However, that's
still pretty useful, and I don't see a reasonable solution that provides
more generality than that in a type-safe way.  I'm quite happy that you
can't write sprintf() using this ;-)

A different line of argument is whether this functionality is
sufficiently badly needed that we should get out in front of the SQL
standard on providing it, and risk being stuck with legacy behavior
if they eventually adopt some other mechanism to solve the same problem.
I'm not sure how worried I am about that.  There are certainly a
boatload of Postgres-isms in and around CREATE FUNCTION already,
so it's hard to make a case against "just one more".

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Andrew DunstanDate: 2008-06-24 02:29:48
Subject: Re: variadic function support
Previous:From: Bruce MomjianDate: 2008-06-23 23:30:53
Subject: Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group