From: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: split TOAST support out of postgres.h |
Date: | 2022-12-29 07:39:34 |
Message-ID: | CAN-LCVM4xnwJz7N7j=Dy=HiAXn-Af7hStr-Z5VSjMK9YzzTneA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I've thought about this while working on Pluggable TOAST and 64-bit
TOAST value ID myself. Agree with #2 to seem the best of the above.
There are not so many places where a new header should be included.
On Wed, Dec 28, 2022 at 6:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> > ... Then we could either
>
> > 1) Include varatt.h in postgres.h, similar to elog.h and palloc.h. That
> > way we clean up the files a bit but don't change any external interfaces.
>
> > 2) Just let everyone who needs it include the new file.
>
> > 3) Compromise: You can avoid most "damage" by having fmgr.h include
> > varatt.h. That satisfies most data types and extension code. That way,
> > there are only a few places that need an explicit include of varatt.h.
>
> > I went with the last option in my patch.
>
> I dunno, #3 seems kind of unprincipled. Also, since fmgr.h is included
> so widely, I doubt it is buying very much in terms of reducing header
> footprint. How bad is it to do #2?
>
> regards, tom lane
>
>
>
--
Regards,
Nikita Malakhov
Postgres Professional
https://postgrespro.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2022-12-29 08:40:52 | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
Previous Message | Peter Geoghegan | 2022-12-29 06:36:53 | Re: Avoiding unnecessary clog lookups while freezing |