Hi,
On 12/10/22 4:55 AM, Nathan Bossart wrote:
On Fri, Dec 09, 2022 at 09:43:56PM -0500, Tom Lane wrote:
Presumably it could be silenced by removing the semicolons after
the new macro calls:
The backslash after the last right brace means that the line
following that is part of the macro body
On Fri, Dec 09, 2022 at 07:55:45PM -0800, Nathan Bossart wrote:
> Indeed. Patch attached.
Yep, thanks. I have exactly the same thing brewing in one of my
staging branches.
--
Michael
signature.asc
Description: PGP signature
On Fri, Dec 09, 2022 at 09:43:56PM -0500, Tom Lane wrote:
> Presumably it could be silenced by removing the semicolons after
> the new macro calls:
> The backslash after the last right brace means that the line
> following that is part of the macro body. This does no harm as
> long as said line i
On Fri, Dec 09, 2022 at 09:43:56PM -0500, Tom Lane wrote:
> Presumably it could be silenced by removing the semicolons after
> the new macro calls:
>
> /* pg_stat_get_analyze_count */
> PG_STAT_GET_RELENTRY_INT64(analyze_count);
>
> /* pg_stat_get_autoanalyze_count */
> PG_STAT_GET_RELENTRY_INT64
This series of patches has caused buildfarm member wrasse to
start complaining about "empty declarations":
wrasse| 2022-12-09 21:08:33 |
"/export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/pgstatfuncs.c",
line 56: warning: syntax error: empty declaration
On Tue, Dec 06, 2022 at 05:28:47AM +0100, Drouvot, Bertrand wrote:
> Fields renaming was mandatory in the previous ones as there was
> already a mix of with/without "n_" in the existing fields names.
>
> That said, I think it's better to rename the fields as you did (to
> be "consistent" on the na
On Tue, Dec 06, 2022 at 12:23:55PM +0530, Bharath Rupireddy wrote:
> Likewise, is there a plan to add function generation macros for
> pg_stat_get_bgwriter, pg_stat_get_xact and so on?
Yes, I saw that and we could do it, but I did not get as much
enthusiastic in terms of code reduction.
--
Michael
On Tue, Dec 6, 2022 at 8:15 AM Michael Paquier wrote:
>
> On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
> > Doing that in a separate patch is fine by me.
>
> I have applied the patch for the tab entries, then could not resist
> poking at the parts for the db entries. This leads
Hi,
On 12/6/22 3:45 AM, Michael Paquier wrote:
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries,
Oops, I missed this part when reading the email the first time and just saw the
patch
Hi,
On 12/6/22 3:45 AM, Michael Paquier wrote:
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries, then could not resist
poking at the parts for the db entries. This leads to more reducti
On Tue, Dec 06, 2022 at 11:45:10AM +0900, Michael Paquier wrote:
> I have applied the patch for the tab entries, then could not resist
> poking at the parts for the db entries. This leads to more reduction
> than the other one actually, as of:
> 4 files changed, 169 insertions(+), 447 deletions(-
On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
> Doing that in a separate patch is fine by me.
I have applied the patch for the tab entries, then could not resist
poking at the parts for the db entries. This leads to more reduction
than the other one actually, as of:
4 files ch
On Mon, Dec 05, 2022 at 09:11:43AM +0100, Drouvot, Bertrand wrote:
> Means, once the current patch is committed, working on [1] and
> "cleaning" the databases one could be done in parallel. Sounds good
> to you?
Doing that in a separate patch is fine by me.
--
Michael
signature.asc
Description:
Hi,
On 12/5/22 8:44 AM, Michael Paquier wrote:
On Mon, Dec 05, 2022 at 08:27:15AM +0100, Drouvot, Bertrand wrote:
On 12/4/22 6:32 PM, Nathan Bossart wrote:
Alright. I marked this as ready-for-committer.
Thanks!
Well, that's kind of nice:
5 files changed, 139 insertions(+), 396 deletions
On Mon, Dec 05, 2022 at 08:27:15AM +0100, Drouvot, Bertrand wrote:
> On 12/4/22 6:32 PM, Nathan Bossart wrote:
>> Alright. I marked this as ready-for-committer.
>
> Thanks!
Well, that's kind of nice:
5 files changed, 139 insertions(+), 396 deletions(-)
And I like removing code, so..
In the sam
Hi,
On 12/4/22 6:32 PM, Nathan Bossart wrote:
On Sun, Dec 04, 2022 at 06:07:37AM +0100, Drouvot, Bertrand wrote:
On 12/3/22 9:16 PM, Nathan Bossart wrote:
Thanks. I editorialized a bit in the attached v3. I'm not sure that my
proposed names for the macros are actually an improvement. WDYT?
On Sun, Dec 04, 2022 at 06:07:37AM +0100, Drouvot, Bertrand wrote:
> On 12/3/22 9:16 PM, Nathan Bossart wrote:
>> Thanks. I editorialized a bit in the attached v3. I'm not sure that my
>> proposed names for the macros are actually an improvement. WDYT?
>
> Thanks! I do prefer the macros definit
Hi,
On 12/3/22 9:16 PM, Nathan Bossart wrote:
On Sat, Dec 03, 2022 at 10:31:19AM +0100, Drouvot, Bertrand wrote:
On 12/3/22 1:51 AM, Nathan Bossart wrote:
Can we hard-code the prefix in the macro? It looks like all of these use
the same one.
Good point! Done in V2 attached.
Thanks. I edi
On Sat, Dec 03, 2022 at 10:31:19AM +0100, Drouvot, Bertrand wrote:
> On 12/3/22 1:51 AM, Nathan Bossart wrote:
>> Can we hard-code the prefix in the macro? It looks like all of these use
>> the same one.
>
> Good point! Done in V2 attached.
Thanks. I editorialized a bit in the attached v3. I'm
Hi,
On 12/3/22 1:51 AM, Nathan Bossart wrote:
Overall, this change looks straightforward, and it saves a couple hundred
lines.
Thanks for looking at it!
On Tue, Nov 22, 2022 at 08:09:22AM +0100, Drouvot, Bertrand wrote:
+/* pg_stat_get_numscans */
+PGSTAT_DEFINE_REL_INT64_FIELD_ACCESSOR(pg
Overall, this change looks straightforward, and it saves a couple hundred
lines.
On Tue, Nov 22, 2022 at 08:09:22AM +0100, Drouvot, Bertrand wrote:
> +/* pg_stat_get_numscans */
> +PGSTAT_DEFINE_REL_INT64_FIELD_ACCESSOR(pg_stat_get_, numscans);
> +
> +/* pg_stat_get_tuples_returned */
> +PGSTAT_DE
21 matches
Mail list logo
