Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 18 Nov 2025 14:39:04 +0900
From: Michael Paquier <michael@paquier.xyz>
To: jian he <jian.universality@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Tomas Vondra <tomas@vondra.me>,
	pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Subject: Re: Extended Statistics set/restore/clear functions.
Message-ID: <aRwGeN7o22HJclg5@paquier.xyz>
References: 
 <CACJufxHZzUeu_fyem2oA_FSrjk0ky5vn_h1Dw68=UVLekXPjXA@mail.gmail.com>
 <CACJufxHP+wZ9Th2U9JW27cCq-me222e76pv7vcjqt+oCL03m5Q@mail.gmail.com>
 <CADkLM=c8-U4GLMw5VdeDdfp1ae6BW=PCfEQqAky04iZMbckCFw@mail.gmail.com>
 <CACJufxFo5b0FvmV4CmOb74NFrXm_znZHh7bLiiVkAzVzTnJiVw@mail.gmail.com>
 <CADkLM=fky861BrifcuWc0CbWfo3yMbRB+m1jG4qqXG_3hnqdtA@mail.gmail.com>
 <CACJufxFni1oB-VFuLbVs9VSgVx0czvoZyoW0z_tJ2kq4E3SXYw@mail.gmail.com>
 <CADkLM=d_mmTn3+ChL-z_ZomwOKT-BssQU+=6_a8WDv6A4b7uAA@mail.gmail.com>
 <aRbLV7Tru3ulO5ru@paquier.xyz>
 <aRrHBj7I4CeV21dj@paquier.xyz>
 <CACJufxGGzkb58BU+YyTa9cBAawhybwk2cPFZ1XupS-8xuAzN9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="CNVCssQdYHpxU7aZ"
Content-Disposition: inline
In-Reply-To: 
 <CACJufxGGzkb58BU+YyTa9cBAawhybwk2cPFZ1XupS-8xuAzN9A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aRwGeN7o22HJclg5%40paquier.xyz>
Precedence: bulk


--CNVCssQdYHpxU7aZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 18, 2025 at 01:07:23PM +0800, jian he wrote:
> + errsave(parse->escontext,
> + errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
> + errmsg("malformed pg_ndistinct: \"%s\"", parse->str),
> + errdetail("Invalid \"%s\" value.",
> +  PG_NDISTINCT_KEY_NDISTINCT));
>=20
> the errdetail is way too generic?
> similar to ``select 'a'::int;``
> we can
> DETAIL:  Invalid input syntax for type integer: "a"
> HINT: "ndistinct" value expected to be a type of integer.
>=20
> what do you think?

That is intentional, as it is intentional to not show the value of the
token in such cases.  This will be mostly used for the import
functions, so I am not sure that it is worth spending time on tuning
all these error cases that one is most likely not going to see as the
main scenarios are going to be through pg_dump/restore, most of the
time in the scope of an upgrade.

> SELECT '[{"attributes" : [2,3], "ndistinct" : 4, "ndistinct" :
> 14}]'::pg_ndistinct;
>                pg_ndistinct
> -------------------------------------------
>  [{"attributes": [2, 3], "ndistinct": 14}]
>=20
> SELECT '[{"attributes" : [2,3], "ndistinct" : 4, "attributes" :
> []}]'::pg_ndistinct;
>                pg_ndistinct
> ------------------------------------------
>  [{"attributes": [2, 3], "ndistinct": 4}]
>=20
> Is the above output what we expected?

Interesting one.  The extra "attributes" should not be required once
we have one set, indeed.
--
Michael

--CNVCssQdYHpxU7aZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkcBngACgkQnvQgOdby
QH21TA//cEuj6loqnc3BqMxP73uv44v5A6JEslgThsVQhtR9jD7EDohNO4BoP3Ak
ARrgFlgu+lWcK6zkO30+espfPcH/V59DJERnOl0fZNy49PbribLHBTDBo9dEwTRQ
CCcW5ZYB2XPYvrZNbVwJRL2AX+tJcoVwye8T1l/c9ya7lGkLld3/xH65bUfD9QVj
1ZBfpW9gPQNVBPq+dqFfjCaYBv7w75U6ksnfrQ+r7JpyyahaB/0hi5JQMhI4h0Md
PuxQbMh0bL+RZuwGBn2t3GRK3U32v/garD1JY5l1TK7t4q+HkTAzsTBYAaZ6wimM
o+c01t/SINKOdZGM51rR/EjUuA5GXPOPkoe7TpXhB1ft82GlC0IqCqBAWjpYs6G2
dw65aSxdjXfRRMbr5hjRxRXezUh2mQkGrxk7dooSoLGrbRDuN/XPeWqlJd9n8Ue3
sa9cg7RKw4jJNPnvMKSmhv2rw+jiNwyhHze0Mht40QQKivDqBFTIkQ0D9L1r5Vek
pII+7UyA7uzDRehsN4PaacYdAWXKkag1WYV5rbgIooG/2H04txR2Q1p0PHgVgZnQ
TzyxCckncOPv1w4D2Q53ux+7XCqD9gZJOExahR8gvmfBDshiPqVBqRcBpA9arHRA
iQwMCEYZMtbQrdo3MR8laNgDml3UjpNUlUlUyK4uNmlFzO1/kok=
=U8UV
-----END PGP SIGNATURE-----

--CNVCssQdYHpxU7aZ--