Re: Efficient slicing/substring of TOAST values (for comment) - Mailing list pgsql-patches

From Tom Lane
Subject Re: Efficient slicing/substring of TOAST values (for comment)
Date
Msg-id 751.1002553596@sss.pgh.pa.us
Whole thread Raw
In response to Efficient slicing/substring of TOAST values (for comment)  (John Gray <jgray@azuli.co.uk>)
Responses Re: Efficient slicing/substring of TOAST values (for  (John Gray <jgray@azuli.co.uk>)
List pgsql-patches
John Gray <jgray@azuli.co.uk> writes:
> 2. Changed e.g. textsubstr and byteasubstr to use this method.
> textsubstr is complicated by the multibyte support -the fast method is
> only applicable in a non-multibyte environment.

More accurately, it's only applicable in single-byte character sets,
which is a useful fraction of the MULTIBYTE world too.  Keep in mind
that MULTIBYTE is likely to default to ON in the near future, so there's
little point in such an exercise if you are going to ifdef it out.
I believe there's a routine somewhere that will tell you whether the
current database encoding is single-byte or multi-byte.

> 3. Added any facility to force a column to have attstorage 'e'. At
> present it appears to be defaulted from typstorage, but I couldn't see
> any problem with changing it after table creation. Would a keyword to
> CREATE TABLE to override the default attstorage be useful?

I've been envisioning adding an ALTER TABLE variant to do this, rather
than mucking up CREATE TABLE --- compare the handling of attstattarget.

> Of course, this may just all be useless feature bloat

No, this has been a to-do item for awhile.  I think it's a tad too late
to think in terms of squeezing it into 7.2, but keep working on it for
7.3.

Have you got any ideas about the update side of the problem?

            regards, tom lane

pgsql-patches by date:

Previous
From: John Gray
Date:
Subject: Efficient slicing/substring of TOAST values (for comment)
Next
From: Patrice Hédé
Date:
Subject: Re: [HACKERS] Unicode combining characters