On 10.01.23 09:48, Peter Eisentraut wrote:
On 10.01.23 08:39, Noah Misch wrote:
On Tue, Jan 10, 2023 at 06:07:49AM +0100, Peter Eisentraut wrote:
On 30.12.22 17:50, Tom Lane wrote:
Peter Eisentraut writes:
On 28.12.22 16:07, Tom Lane wrote:
I dunno, #3 seems kind of unprincipled. Also, sinc
On Wed, Jan 11, 2023 at 1:14 AM Noah Misch wrote:
> If the patch had just made postgres.h include varatt.h, like it does elog.h,
> I'd consider that change a nonnegative. Grouping things is nice, even if it
> makes compilation a bit slower. That also covers your frontend use case. How
> about t
On Tue, Jan 10, 2023 at 12:00:46PM -0500, Robert Haas wrote:
> On Tue, Jan 10, 2023 at 9:46 AM Tom Lane wrote:
> > Now, there is a fair question whether splitting this code out of
> > postgres.h is worth any trouble at all. TBH my initial reaction
> > had been "no". But once we found that only 4
On Tue, Jan 10, 2023 at 9:46 AM Tom Lane wrote:
> Now, there is a fair question whether splitting this code out of
> postgres.h is worth any trouble at all. TBH my initial reaction
> had been "no". But once we found that only 40-ish backend files
> need to read this new header, I became a "yes"
Robert Haas writes:
> On Tue, Jan 10, 2023 at 3:48 AM Peter Eisentraut
> wrote:
>>> SET_VARSIZE alone appears in 74 pgxn distributions, so I predict extension
>>> breakage en masse. I would revert this.
>> Well, that was sort of my thinking, but people seemed to like this. I'm
>> happy to cons
On Tue, Jan 10, 2023 at 3:48 AM Peter Eisentraut
wrote:
> >>> Wow, 41 files requiring varatt.h is a lot fewer than I would have guessed.
> >>> I think that bears out my feeling that fmgr.h wasn't a great location:
> >>> I count 117 #includes of that, many of which are in .h files themselves
> >>>
On 10.01.23 08:39, Noah Misch wrote:
On Tue, Jan 10, 2023 at 06:07:49AM +0100, Peter Eisentraut wrote:
On 30.12.22 17:50, Tom Lane wrote:
Peter Eisentraut writes:
On 28.12.22 16:07, Tom Lane wrote:
I dunno, #3 seems kind of unprincipled. Also, since fmgr.h is included
so widely, I doubt it
On Tue, Jan 10, 2023 at 06:07:49AM +0100, Peter Eisentraut wrote:
> On 30.12.22 17:50, Tom Lane wrote:
> >Peter Eisentraut writes:
> >>On 28.12.22 16:07, Tom Lane wrote:
> >>>I dunno, #3 seems kind of unprincipled. Also, since fmgr.h is included
> >>>so widely, I doubt it is buying very much in t
On 30.12.22 17:50, Tom Lane wrote:
Peter Eisentraut writes:
On 28.12.22 16:07, Tom Lane wrote:
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?
See this increment
On 2022-12-30 Fr 11:50, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 28.12.22 16:07, Tom Lane wrote:
>>> 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?
>
Peter Eisentraut writes:
> On 28.12.22 16:07, Tom Lane wrote:
>> 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?
> See this incremental patch set.
Wow, 41 files
On 28.12.22 16:07, Tom Lane wrote:
Peter Eisentraut 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.
Matthias van de Meent writes:
> On Thu, 29 Dec 2022 at 18:16, Andres Freund wrote:
>> We have a bunch of toast*.h files already. The new header should pretty much
>> only contain the types, given how widely the header is going to be
>> included. So maybe toast_type.h?
> My 2 cents: I don't think
On Thu, 29 Dec 2022 at 18:16, Andres Freund wrote:
>
> Hi,
>
> On 2022-12-28 09:07:12 -0500, Isaac Morland wrote:
> > This is a bit of a bikeshed suggestion, but I'm wondering if you considered
> > calling it toast.h? Only because the word is so distinctive within
> > Postgres; everybody knows exa
Hi,
On 2022-12-28 09:07:12 -0500, Isaac Morland wrote:
> This is a bit of a bikeshed suggestion, but I'm wondering if you considered
> calling it toast.h? Only because the word is so distinctive within
> Postgres; everybody knows exactly to what it refers.
We have a bunch of toast*.h files alread
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 wrote:
> Peter Eisentraut writes:
> > ... The
Peter Eisentraut 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 mo
On Wed, 28 Dec 2022 at 08:07, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> Most backend code doesn't actually need the variable-length data types
> support (TOAST support) in postgres.h. So I figured we could try to put
> it into a separate header file. That makes postgres.h mo
Most backend code doesn't actually need the variable-length data types
support (TOAST support) in postgres.h. So I figured we could try to put
it into a separate header file. That makes postgres.h more manageable,
and it avoids including a bunch of complicated unused stuff everywhere.
I picke
19 matches
Mail list logo
