From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: CREATE CONVERSION |
Date: | 2002-07-05 15:50:38 |
Message-ID: | 11522.1025884238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>> Doesn't a conversion currently require several support functions?
>> How much overhead will you be adding to funnel them all through
>> one function?
> No, only one function is sufficient. What else do you think of?
I see two different functions linked to from each pg_wchar_table
entry... although perhaps those are associated with encodings
not with conversions.
>> Basically I'd like to see a spec for the API of the conversion
>> function...
> That would be very simple (the previous example I gave was unnecessary
> complex). The function signature would look like:
> conversion_funcion(TEXT) RETURNS TEXT
> It receives source text and converts it then returns it. That's all.
IIRC the existing conversion functions deal in C string pointers and
lengths. I'm a little worried about the extra overhead implicit
in converting to a TEXT object and back again; that probably means at
least two more palloc and memcpy operations. I think you'd be better
off sticking to a C-level API, because I really don't believe that
anyone is going to code conversion functions in (say) plpgsql.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2002-07-05 16:24:37 | Typo in htup.h comment |
Previous Message | Zeugswetter Andreas SB SD | 2002-07-05 15:39:09 | Re: Issues Outstanding for Point In Time Recovery (PITR) |