| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> | 
|---|---|
| To: | Jubilee Young <workingjubilee(at)gmail(dot)com> | 
| Cc: | John Naylor <johncnaylorls(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: Hide exposed impl detail of wchar.c | 
| Date: | 2023-11-20 22:52:22 | 
| Message-ID: | 20231120225222.GA3474027@nathanxps13 | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, Nov 20, 2023 at 10:50:36AM -0800, Jubilee Young wrote:
> In that case, I took a look across the codebase and saw a
> utils/ascii.h that doesn't
> seem to have gotten much love, but I suppose one could argue that it's intended
> to be a backend-only header file?
That might work.  It's not #included in very many files, so adding
port/simd.h shouldn't be too bad.  And ascii.h is also pretty inexpensive,
so including it in wchar.c seems permissible, too.  I'm not certain this
doesn't cause problems with libpgcommon, but I don't see why it would,
either.
> So it should probably end up living somewhere near the UTF-8 support, and
> the easiest way to make it not go into something pgrx currently
> includes would be
> to make it a new header file, though there's a fair amount of API we
> don't touch.
Does pgrx use ascii.h at all?
-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size | 
|---|---|---|
| move_is_valid_ascii_v2.patch | text/x-diff | 4.8 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-11-20 22:55:32 | Re: PANIC serves too many masters | 
| Previous Message | Bruce Momjian | 2023-11-20 22:48:42 | Re: Partial aggregates pushdown |