| 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 |