From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Don't allocate IndexAmRoutine dynamically? |
Date: | 2019-06-25 21:06:09 |
Message-ID: | 20190625210609.4lbkgsdmyl6bvycs@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-06-25 16:15:17 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I think it might be worthwhile require that IndexAmRoutine returned by
> > amhandler are allocated statically.
>
> +1. Could only be an issue if somebody were tempted to have time-varying
> entries in them, but it's hard to see why that could be a good idea.
Yea, that seems like a use case we wouldn't want to support. If
something like that is needed, they ought to store it in the relcache.
> Should we enforce this for *all* handler objects? If only index AMs,
> why only them?
Well, tableams do that already. Other than indexam and tableam I think
there's also FDW and TSM routines - are there any others? Changing the
FDW API seems like it'd incur some work to a lot more people than any of
the others - I'm not sure it's worth it.
> > It seems to me like there's not that many index AMs out there, so
> > changing the signature of amhandler() to require returning a const
> > pointer to a const object ought to both be enough of a warning, and not
> > too big a burden.
>
> One too many "consts" there. Pointer to const object seems fine.
> The other part is either meaningless or will cause problems.
Yea - I was thinking of the pointer in RelationData, where having it as
const *Routine const; would make sense (but it's annoying to do without
invoking technically undefined behaviour, doing ugly things with memcpy
or duplicating struct definitions).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-06-25 21:25:12 | Re: Don't allocate IndexAmRoutine dynamically? |
Previous Message | James Coleman | 2019-06-25 20:53:40 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |