Re: NAMEDATALEN increase because of non-latin languages

On Fri, Jun 24, 2022 at 4:49 AM Andres Freund <andres@anarazel.de> wrote:
> A first step could be to transform code like
>     (Form_pg_attribute) GETSTRUCT(tuple)
> into
>    GETSTRUCT(pg_attribute, tuple)

To get the ball rolling, I've done this much in 0001. This is an easy
mechanical change, although we'll next want a third argument to pass
the Form_* pointer.

0002 changes this macro to

#define GETSTRUCT(CAT, TUP) Deform_##CAT##_tuple((char *)
((TUP)->t_data) + (TUP)->t_data->t_hoff)

...where genbki.pl generates stub macros in the form of

#define Deform_pg_am_tuple(TUP) (Form_pg_am) (TUP)

...which live in pg_*_deform.h and are #included into each main
catalog header after the Form_* is defined. Feedback on whether a more
tasteful way should be sought would be appreciated.

While not very interesting on its own, it gives an idea of how the
build would work. Next step would be to turn these into functions like

static inline void
Deform_pg_am_tuple(Form_pg_am, char * tuple)
{...}

that just memcpy() things over as already discussed, adjusting the
callers of GETSTRUCT to match. This won't be quite as mechanical and
will require some manual work since some not least because some call
sites mix declaration and assignment. I imagine there will also be a
need for the inverse operation, forming a tuple from a struct.

We will also have to take care to work around cases where the Form_*
pointer is currently used for in-place updates. I imagine there are
not many, but they will require extra care. The pseudo-catalog
pg_sequence_data is an example, and a bit of a special case anyway.

On Fri, Jun 24, 2022 at 1:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sounds worth investigating, anyway.  It'd also get us out from under
> C-struct-related problems such as the nearby AIX alignment issue.

Getting around that issue sounds like a good first goal for committing.

--
John Naylor
EDB: http://www.enterprisedb.com