Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Update patch applied; I also adjusted some translation function calls.
> > The new output of psql \d+ is:
> >
> > test=> \d+ test
> > Table "public.test"
> > Column | Type | Modifiers | Storage | Description
> >
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> Here is the patches he made against CVS HEAD (as of today).
>
> According to him followings are fixed with the patches:
>
> - fix crush with DISTINCT
> - fix creating VIEW
> - fix the case when recursion plan has another recursion pl
Bruce Momjian wrote:
> Update patch applied; I also adjusted some translation function calls.
> The new output of psql \d+ is:
>
> test=> \d+ test
>Table "public.test"
>Column | Type | Modifiers | Storage | Description
> +-+-
Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > This seems to be against an older version of psql ... with the
> > printTable API stuff, we reworked this -- in particular the mbvalidate()
> > call that's only on WIN32 is gone (actually it's the lack of it that's
> > gone.
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> sample: select mleast(variadic array[1,2,3,4,5]);
One other point here: in the patch as presently submitted, VARIADIC
can't be an unreserved keyword, but it seems to be enough to make it a
col_name_keyword. Some preliminary testing says that that does
2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
>>> Are you intending to change this right now and resubmit, or is it
>>> work for later?
>
>> I prefer separate it to other patch.
>
> It seems a fairly important part o
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
>> Are you intending to change this right now and resubmit, or is it
>> work for later?
> I prefer separate it to other patch.
It seems a fairly important part of the feature, especially given the
connection to
2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> sample: select mleast(variadic array[1,2,3,4,5]);
>
> Note this would also address Jeff's complaint about not being able to
> pass zero variadic parameters:
>
> select mleast(variadic array[]::int[]);
>
> Looks
Jeff Davis <[EMAIL PROTECTED]> writes:
> I don't have a strong opinion, but allowing zero-argument variadic
> function calls -- and therefore causing foo(variadic int[]) and
> foo(variadic text[]) to conflict -- makes more sense than requiring one
> argument.
I hadn't even thought about that point
On Sun, 2008-07-13 at 12:32 -0400, Tom Lane wrote:
> >> Also, it doesn't seem to allow calls to a variadic function with zero
> >> arguments, e.g. "mleast()". I think this should be allowed.
>
> > It's not possible for all cases, because empty array have be typed
> > array still. But for non polym
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> sample: select mleast(variadic array[1,2,3,4,5]);
Note this would also address Jeff's complaint about not being able to
pass zero variadic parameters:
select mleast(variadic array[]::int[]);
Looks a bit ugly but the type is specified, so it would wor
2008/7/14 Florian G. Pflug <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>>
>>> One issue that just occurred to me: what if a variadic function wants to
>>> turn around and call another variadic function, passing the same array
>>> argument on to the second one? This is closely akin
>>> to the pro
Pavel Stehule wrote:
One issue that just occurred to me: what if a variadic function
wants to turn around and call another variadic function, passing
the same array argument on to the second one? This is closely akin
to the problem faced by C "..." functions, and the solutions are
pretty ugly
2008/7/13 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
>>> Also, it doesn't seem to allow calls to a variadic function with zero
>>> arguments, e.g. "mleast()". I think this should be allowed.
>
>> It's not possible for all
>
> As far as the "variadic int" versus "variadic int[]" business, I'm
> starting to agree with Pavel that "variadic int[]" offers less potential
> for confusion. In particular, it seems to make it more obvious for the
> function author that the argument he receives is an array. Also, the
> other
15 matches
Mail list logo
