> Joe Conway <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
> 3. Set up a long-lived cache internal to the array functions that can
> translate element type OID to the needed lookup data, and won't leak
> memory across repeated calls. This is not the fastest or most general
> solution, but it seem
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 3. Set up a long-lived cache internal to the array functions that can
>> translate element type OID to the needed lookup data, and won't leak
>> memory across repeated calls. This is not the fastest or most general
>> solution, but it see
Tom Lane wrote:
Bertrand Petit <[EMAIL PROTECTED]> writes:
And I just got another one, much simpler, that failed the same
way with the same data set:
UPDATE rimdb_atitles SET aka_title=convert(byte_title,charset,'UTF8');
[ where rimdb_atitles has an index on column "attribs varchar[]" ]
Uh
> I can think of a number of ways we might attack this, but none seem
> especially attractive ---
>
> 1. Have the index AMs create and switch into a special memory context
> for each call, rather than running in the main execution context.
> I am not sure this is workable at all, since the AMs ten
Bertrand Petit <[EMAIL PROTECTED]> writes:
> And I just got another one, much simpler, that failed the same
> way with the same data set:
> UPDATE rimdb_atitles SET aka_title=convert(byte_title,charset,'UTF8');
[ where rimdb_atitles has an index on column "attribs varchar[]" ]
Uh-huh. Actu
