| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Update comments in functions for statistics import in postgres_fdw.c |
| Date: | 2026-11-11 00:38:46 |
| Message-ID: | 3A78EF0B-236F-460A-B284-3FE7EDF5F6E0@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Nov 10, 2026, at 18:04, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
>
> On Tue, Nov 10, 2026 at 6:50 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
>> As I understand it, you are saying we need to separate the version
>> parameter from statistical value parameters, but the comment for
>> import_attribute_statistics says:
>>
>> * Import attribute statistics from NullableDatum inputs for all statistical
>> * values.
>> *
>> * For now, the 'version' argument is ignored. In the future it can be used
>> * to interpret older statistics properly.
>>
>> So IMU I think we are using the term "statistical value parameters" to
>> include the version parameter. With that in mind, what I proposed is
>> not that bad...
>
> I mean the term "statistical values" includes a version value. Sorry.
>
> Best regards,
> Etsuro Fujita
I was considering the version parameter as metadata for the statistical values, which could be used to distinguish between different sets of statistical values. But I see your point now. Treating the version parameter as a statistical value parameter also makes sense to me. No objection from my side.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-11-11 00:56:06 | Re: [PATCH] doc: Fix pg_combinebackup's description of --sync-method |
| Previous Message | Xuneng Zhou | 2026-11-11 00:35:13 | Re: Add a hint to the "WAL summaries are required" errors |