Peter Eisentraut writes:
> On 16.05.24 16:45, Tom Lane wrote:
>> Yeah, that was bothering me too, but I went for the minimum delta.
>> I did think that a couple of integer macros would be a better idea,
>> so +1 for what you did here.
> I committed this, and Michael took care of
On 16.05.24 16:45, Tom Lane wrote:
Peter Eisentraut writes:
In these cases, I think for
NotificationHash
ResourceOwnerData
WalSyncMethod
we can just get rid of the typedef.
I have no objection to dealing with NotificationHash as you have here.
ReadBuffersFlags shouldn't be an enum at all,
On Fri, May 17, 2024 at 10:24:57AM +0900, Michael Paquier wrote:
> Yep. I can handle that in 2~3 hours.
And done with 110eb4aefbad. If there's anything else, feel free to
let me know.
--
Michael
signature.asc
Description: PGP signature
On Thu, May 16, 2024 at 09:09:36PM -0400, Tom Lane wrote:
> WFM, and this is probably a place where we don't want to change the
> API in v17 and again in v18, so I agree with pushing now.
>
> Reminder though: beta1 release freeze begins Saturday.
> Not many hours left.
Yep. I can handle that in
Michael Paquier writes:
> On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
>> ... I think the enum should be nuked altogether, but
>> it's a bit late to be redesigning that for v17 perhaps.
> You're right, WaitEventExtension is better gone. The only thing that
> matters is that we want
On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
> I am also quite confused by that. It seems to be kind of an enum
> that is supposed to be extended at runtime, meaning that neither
> of the existing enum member values ought to be used as such, although
> either autoprewarm.c didn't get
Peter Eisentraut writes:
> In these cases, I think for
> NotificationHash
> ResourceOwnerData
> WalSyncMethod
> we can just get rid of the typedef.
I have no objection to dealing with NotificationHash as you have here.
> ReadBuffersFlags shouldn't be an enum at all, because its values are
>
On 16.05.24 01:32, Tom Lane wrote:
As for the remainder, they aren't showing up because no variable
or field is declared using them, which means no debug symbol
table entry is made for them. This means we could just drop those
typedefs and be little the worse off notationally. I experimented
I wrote:
> This works for me. One point that could stand discussion while we're
> here is whether the once-a-cycle run should use the verbatim buildfarm
> results or it's okay to editorialize on that typedefs list. I did a
> little of the latter in da256a4a7, and I feel like we should either
>
On Wed, May 15, 2024 at 04:52:19PM -0400, Robert Haas wrote:
> On Wed, May 15, 2024 at 4:50 PM Tom Lane wrote:
>> At this point my OCD got the better of me and I did a little
>> additional wordsmithing. How about the attached?
>
> No objections here.
+1
--
Nathan Bossart
Amazon Web Services:
On Wed, May 15, 2024 at 4:50 PM Tom Lane wrote:
> At this point my OCD got the better of me and I did a little
> additional wordsmithing. How about the attached?
No objections here.
--
Robert Haas
EDB: http://www.enterprisedb.com
Nathan Bossart writes:
> On Wed, May 15, 2024 at 04:07:18PM -0400, Robert Haas wrote:
>> How's this?
> I compared this with my v1, and the only bit of information there that I
> see missing in v3 is that validation step 4 only applies in the
> once-per-cycle run (or if you forget to pgindent
On Wed, May 15, 2024 at 04:07:18PM -0400, Robert Haas wrote:
> On Wed, May 15, 2024 at 3:30 PM Nathan Bossart
> wrote:
>> This is much cleaner, thanks. The only thing that stands out to me is that
>> the "once per release cycle" section should probably say to do an indent
>> run after
Robert Haas writes:
> On Wed, May 15, 2024 at 3:30 PM Nathan Bossart
> wrote:
>> This is much cleaner, thanks. The only thing that stands out to me is that
>> the "once per release cycle" section should probably say to do an indent
>> run after downloading the typedef file.
> How's this?
On Wed, May 15, 2024 at 3:30 PM Nathan Bossart wrote:
> On Wed, May 15, 2024 at 12:06:03PM -0400, Robert Haas wrote:
> > What jumps out at me when I read this patch is that it says that an
> > incremental run should do steps 1-3 of a complete run, and then
> > immediately backtracks and says not
On Wed, May 15, 2024 at 12:06:03PM -0400, Robert Haas wrote:
> What jumps out at me when I read this patch is that it says that an
> incremental run should do steps 1-3 of a complete run, and then
> immediately backtracks and says not to do step 2, which seems a little
> strange.
>
> I played
On Tue, Apr 23, 2024 at 4:05 PM Nathan Bossart wrote:
> Here is a first attempt. I'm not tremendously happy with it, but it at
> least gets something on the page to build on. I was originally going to
> copy/paste the relevant steps into the description of the incremental
> process, but that
Andrew Dunstan writes:
> On 2024-04-24 We 06:12, Peter Eisentraut wrote:
>> Is the code to extract typedefs available somewhere independent of the
>> buildfarm? It would be useful sometimes to be able to run this
>> locally, like before and after some patch, to keep the in-tree
>> typedefs
On 2024-04-24 We 06:12, Peter Eisentraut wrote:
On 22.04.24 22:28, Tom Lane wrote:
Nathan Bossart writes:
On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
I think the actual plan now is that we'll sync the in-tree copy
with the buildfarm's results (and then do a tree-wide
On 22.04.24 22:28, Tom Lane wrote:
Nathan Bossart writes:
On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
I think the actual plan now is that we'll sync the in-tree copy
with the buildfarm's results (and then do a tree-wide pgindent)
every so often, probably shortly before beta
On 2024-04-23 Tu 06:23, Alvaro Herrera wrote:
But there are others: InjectionPointEntry, ResourceOwnerData,
JsonNonTerminal, JsonParserSem, ...
The last two are down to me. Let's just get rid of them like the
attached (no need for a typedef at all)
cheers
andrew
--
Andrew Dunstan
On Mon, Apr 22, 2024 at 03:20:10PM -0500, Nathan Bossart wrote:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> The problem with the README is that it describes that process,
>> rather than the now-typical workflow of incrementally keeping
>> the tree indented. I don't think we
Alvaro Herrera writes:
> On 2024-Apr-22, Tom Lane wrote:
>> The main reason there's a delta is that people don't manage to
>> maintain the in-tree copy perfectly (at least, they certainly
>> haven't done so for this past year). So we need to do that
>> to clean up every now and then.
> Out of
On Tue, Apr 23, 2024 at 6:23 AM Alvaro Herrera wrote:
> I wonder if we're interested in keeping a (very short) manually-
> maintained list of symbols that we know are in use but the scripts
> don't extract for whatever reason.
+1. I think this idea has been proposed and rejected before, but I
On 2024-Apr-22, Tom Lane wrote:
> The main reason there's a delta is that people don't manage to
> maintain the in-tree copy perfectly (at least, they certainly
> haven't done so for this past year). So we need to do that
> to clean up every now and then.
Out of curiosity, I downloaded the
Nathan Bossart writes:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> I think the actual plan now is that we'll sync the in-tree copy
>> with the buildfarm's results (and then do a tree-wide pgindent)
>> every so often, probably shortly before beta every year.
> Okay. Is this
On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
> I think the actual plan now is that we'll sync the in-tree copy
> with the buildfarm's results (and then do a tree-wide pgindent)
> every so often, probably shortly before beta every year.
Okay. Is this just to resolve the delta between
Nathan Bossart writes:
> I used to do this step when I first started hacking on Postgres because
> that's what it says to do, but I've only ever used the in-tree one for many
> years now, and I'm not aware of any scenario where I might need to download
> a new version from the buildfarm. I see
I used to do this step when I first started hacking on Postgres because
that's what it says to do, but I've only ever used the in-tree one for many
years now, and I'm not aware of any scenario where I might need to download
a new version from the buildfarm. I see that the in-tree copy wasn't
29 matches
Mail list logo
