There's certainly a TODO, but I'm not yet 100% sure that the solution
Jon proposed is best. I'm looking at it as we write, and making it work
looks to be somewhat complex. If we go that road we would probably need
to generalise somewhat the COPY code.
The alternative in my mind is some function foo such that foo(e) = 'e'
Comments are welcome - this is virgin ground for me :-)
andrew
Bruce Momjian wrote:
>Is there a TODO here? The only problem I see is that it introduces the
>idea of special column-1 handling, which we don't have right now, except
>in COPY.
>
>---------------------------------------------------------------------------
>
>Andrew Dunstan wrote:
>
>
>>Jon Jensen wrote:
>>
>>
>>
>>>On Thu, 28 Aug 2003, Andrew Dunstan wrote:
>>>
>>>
>>>
>>>
>>>
>>>>What is the state of things regarding having to use massive strings of
>>>>quotes like this (taken from the 7.3 docs)?:
>>>>
>>>>a_output := a_output || '' if v_'' ||
>>>> referrer_keys.kind || '' like ''''''''''
>>>> || referrer_keys.key_string || ''''''''''
>>>> then return '''''' || referrer_keys.referrer_type
>>>> || ''''''; end if;'';
>>>>
>>>>This is truly ugly, IMNSHO. Perl has its q() construct - any chance of
>>>>us doing something here?
>>>>
>>>>I'm prepared to put in effort to implement a solution if there is
>>>>agreement on what the solution should be. Maybe some sort of magical
>>>>operator/function?
>>>>
>>>>
>>>>
>>>>
>>>I was thinking the most natural thing would be to use something similar to
>>>COPY's stdin quoting:
>>>
>>>CREATE FUNCTION bob() RETURNS INTEGER AS stdin LANGUAGE 'plpgsql';
>>>BEGIN
>>> ...
>>>END;
>>>\.
>>>
>>>Another possibility would be shell/Perl-style here documents, like this:
>>>
>>>CREATE FUNCTION bob() RETURNS INTEGER AS <<EOF
>>>BEGIN
>>> ...
>>>END;
>>>EOF
>>>LANGUAGE 'plpgsql';
>>>
>>>The former seems preferable since it uses a syntax PostgreSQL already
>>>supports in another context.
>>>
>>>Jon
>>>
>>>
>>>
>>>
>>Nice idea. I would probably never have thought of it :-) Makes function
>>text almost first class, in the way that Oracle's is AFAICS,
>>
>>I also prefer the first version, not least because it hoists the
>>LANGUAGE clause to the top where it seems to me it belongs.
>>
>>I have no idea how hard this would be.
>>
>>
>>cheers
>>
>>andrew
>>
>>
>>