Re: Calling function from VFP changes character field to Memo

On 11/15/22 10:54 AM, Frank Cazabon wrote:
> 
> On 15/11/2022 2:44 pm, Tom Lane wrote:
>> Frank Cazabon <frank.cazabon@gmail.com> writes:
>>> If however I have a function defined like this
>>> CREATE OR REPLACE FUNCTION public.testfunction(
>>>       )
>>>       RETURNS TABLE
>>>       (
>>>           Firstname character(30)
>>>       )
>>>       LANGUAGE 'plpgsql'
>>> AS $BODY$
>>> BEGIN
>>>       RETURN QUERY SELECT p.cFirstName FROM patients p;
>>> END;
>>> $BODY$;
>>> And I call:
>>> SELECT * FROM public.testFunction();
>>> Then FirstName returns as a Memo field (similar to a Text field).
>> This is mostly about whatever software stack you're using on the
>> client side --- Memo is certainly not something Postgres knows about.
>>
>>> Any idea what I need to do to get it to return the character(30) type?
>> There's no chance of getting back the "30" part with this structure,
>> because function signatures do not carry length restrictions.
>> What I expect is happening is that you get firstname as an
>> unspecified-length "character" type, and something on the client
>> side is deciding to cope with that by calling it "Memo" instead.
>>
>> You could perhaps work around that by defining a named composite
>> type:
>>
>> create type testfunction_result as (firstname character(30), ...);
>>
>> create function testfunction() returns setof testfunction_result as ...
>>
>>             regards, tom lane
> Thanks, so I could define the function like this - removed the (30):
> 
> CREATE OR REPLACE FUNCTION public.testfunction(
>       )
>       RETURNS TABLE
>       (
>           Firstname character
>       )
>       LANGUAGE 'plpgsql'

No you don't want to do that:

select 'test'::char;
  bpchar
--------
  t

vs

select 'test'::varchar;
  varchar
---------
  test

Besides you missed the important part, after creating the type 
testfunction_result:

create function testfunction() returns setof testfunction_result as ...


> 
> I'll try the type definition and see if that helps.
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com