On Mon, Jul 08, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Let me show you other error types for discussion/classification:
> SELECT pg_describe_object(1::regclass, 0, 0);
>
> ERROR: XX000: unsupported object class: 1
> LOCATION: getObjectDescription, objectaddress.c:4016
> or
> SELECT pg_identify_object_as_address('1'::regclass, 1, 1);
>
> ERROR: XX000: unsupported object class: 1
> LOCATION: getObjectTypeDescription, objectaddress.c:4597
These ones are old enough, indeed. Knowing that they usually come
down to be used with scans of pg_shdepend and pg_depend to get some
information about the objects involved, I've never come down to see if
these were really worth tackling. The cases of dropped/undefined
case is much more interesting, because we may give in input object IDs
that have been dropped concurrently. Class IDs are constants fixed in
time.
> --
> SELECT format('BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> SET TRANSACTION SNAPSHOT ''%s''', repeat('-', 1000))
> \gexec
> ERROR: XX000: could not open file "pg_snapshots/-----...---" for reading: File name too long
> LOCATION: ImportSnapshot, snapmgr.c:1428
This one is fun. errcode_for_file_access() does not know about
ENAMETOOLONG, as an effect of the errno returned by AllocateFile().
Perhaps it should map to ERRCODE_NAME_TOO_LONG?
> CREATE OPERATOR === (leftarg = int4, rightarg = int4, procedure = int4eq,
> commutator = ===, hashes);
>
> CREATE TABLE t1 (a int);
> ANALYZE t1;
> CREATE TABLE t2 (a int);
>
> SELECT * FROM t1, t2 WHERE t1.a === t2.a;
>
> ERROR: XX000: could not find hash function for hash operator 16385
> LOCATION: ExecHashTableCreate, nodeHash.c:560
Hehe. You are telling that this operator supports a hash join, but
nope. I am not really convinced that this is worth worrying.
> --
> WITH RECURSIVE oq(x) AS (
> WITH iq as (SELECT * FROM oq)
> SELECT * FROM iq
> UNION
> SELECT * from iq
> )
> SELECT * FROM oq;
>
> ERROR: XX000: missing recursive reference
> LOCATION: checkWellFormedRecursion, parse_cte.c:896
> (commented as "should not happen", but still...)
Hmm. This one feels like a bug, indeed.
> --
> CREATE EXTENSION ltree;
> SELECT '1' ::ltree @ (repeat('!', 100)) ::ltxtquery;
>
> ERROR: XX000: stack too short
> LOCATION: makepol, ltxtquery_io.c:252
ltree has little maintenance, not sure that's worth worrying.
> I'm not mentioning errors, that require more analysis and maybe correcting
> the surrounding logic, not ERRCODE only.
>
> Maybe it makes sense to separate the discussion of such errors, which are
> not triggered by tests/not covered; I'm just not sure how to handle them
> efficiently.
The scope is too broad for some of them like the CTE case, so separate
threads to attract the correct review audience makes sense to me.
--
Michael
