Re: Proposal: CREATE CONVERSION - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: CREATE CONVERSION
Date
Msg-id 11522.1025884238@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: CREATE CONVERSION  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: Proposal: CREATE CONVERSION  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.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




pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Proposal: CREATE CONVERSION
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Issues Outstanding for Point In Time Recovery (PITR)