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));
>
> 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.
>
> 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}]
>
> SELECT '[{"attributes" : [2,3], "ndistinct" : 4, "attributes" :
> []}]'::pg_ndistinct;
> pg_ndistinct
> ------------------------------------------
> [{"attributes": [2, 3], "ndistinct": 4}]
>
> Is the above output what we expected?
Interesting one. The extra "attributes" should not be required once
we have one set, indeed.
--
Michael
