On 14.05.2010 22:24, guillaume@lelarge.info wrote:
> Le 14/05/2010 13:42, Dave Page a écrit :
>
>> On Fri, May 14, 2010 at 12:32 PM, Erwin Brandstetter
>> <brandstetter@falter.at> wrote:
>>
>>> On 14.05.2010 08:49, guillaume@lelarge.info wrote:
>>>
>>>> Hi Erwin,
>>>>
>>>> Le 14/05/2010 04:35, Erwin Brandstetter a écrit :
>>>>
>>>>
>>>>> [...]
>>>>> On further testing 1.10.3 beta on Win XP Pro I found a bug that might be
>>>>> a show-stopper.
>>>>> See ticket #188.
>>>>>
>>>>>
>>>>>
>>>> Can you give us the real statement to create that function?
>>>>
>>>>
>>> I have tested with a variety of fuctions. Any function returning TABLE()
>>> will trigger the error. Example:
>>>
>>> CREATE FUNCTION foo (IN integer)
>>> RETURNS TABLE(a integer, b integer) AS
>>> $BODY$
>>> SELECT 1,2;
>>> $BODY$
>>> LANGUAGE 'sql';
>>>
>>> Then try changing anything via function properties.
>>>
> OK. Fixed.
>
>
>> Unfortunately it's too late to stop the show now (due to the
>> PostgreSQL build schedule, and pgCon next week). We can push out an
>> additional update in a week or so if we like.
>>
>>
> Not sure we really need to. This bug only occured for TABLE-returning
> functions and was already there before 1.10.3
The major reason why I did not find the bug earlier ist that the reverse
engineered SQL for TABLE-returning functions was broken up until 1.10.2
(ticket #159). Therefore I avoided this notation and substituted the
(for SET-returning functions) inferior OUT-Parameter notation. Now, that
the SQL is fixed, I started to make use of the RETURNS TABLE() notation
and the problem popped up. I expect more people to run into this now.
If we decide not to got for 1.10.4 maybe we should add a "known bugs"
disclaimer on the webside?
Regards
Erwin