On 2019-Jan-11, Andres Freund wrote:
> Just as an example of why I think this isn't great:
Hmm, to me, the first example is much better because of *vertical* space
-- I can have the whole API in one screenful. In the other example, the
same number of functions take many more lines. The fact tha
Hi,
On 2019-01-11 09:42:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The pluggable storage patchset has a large struct full of callbacks, and
> > a bunch of wrapper functions for calling those callbacks. While
> > starting to polish the patchset, I tried to make the formatting nice.
> >
Hi,
On 2019-01-11 10:32:03 -0500, Robert Haas wrote:
> On Thu, Jan 10, 2019 at 11:45 PM Andres Freund wrote:
> > void(*relation_set_new_filenode) (Relation relation,
> > char persistence,
> > T
On Fri, Jan 11, 2019 at 9:42 AM Tom Lane wrote:
> Use shorter method names? This sounds like an ugly workaround for
> a carpal-tunnel-syndrome-inducing design.
What would you suggest instead of something like
"relation_set_new_filenode"? I agree that shorter names have some
merit, but it's not
On Thu, Jan 10, 2019 at 11:45 PM Andres Freund wrote:
> void(*relation_set_new_filenode) (Relation relation,
> char persistence,
> TransactionId *freezeXid,
>
Andres Freund writes:
> The pluggable storage patchset has a large struct full of callbacks, and
> a bunch of wrapper functions for calling those callbacks. While
> starting to polish the patchset, I tried to make the formatting nice.
> ...
> So, putting the parameter list, both in use and declara
Hi,
The pluggable storage patchset has a large struct full of callbacks, and
a bunch of wrapper functions for calling those callbacks. While
starting to polish the patchset, I tried to make the formatting nice.
By default pgindent yields formatting like:
/*
* API struct for a table AM. Note th
