From: | Steve Lau <stevelauc(at)outlook(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Doc of typmod arg perhaps deserves an update |
Date: | 2024-10-11 05:33:54 |
Message-ID: | B1F029FF-E8CC-4A4A-B74E-7250C5DD77F0@outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
# Context
I hit the issue described in this thread when building my toy pgvector implementation: https://www.postgresql.org/message-id/162867790903161317q178e11e6ie276d1254c279dd1%40mail.gmail.com, TLDR of the thread is that: When you define a new custom type that needs a type modifier, it is possible (I would say highly possible in my case) that you won’t receive the stored typmod in this type’s input function’s third argument even though it is **stored** in a column’s metadata.
# Documentation of CREATE TYPE perhaps needs more elaboration
The documentation of CREATE TYPE (https://www.postgresql.org/docs/current/sql-createtype.html) says that
“and the third is the typmod of the destination column, if known (-1 will be passed if not).”
Before hitting the issue, I thought -1 will be passed if and only if this type does not have type modifiers, as it is indeed unknown. However, it surprises me that it could also be unknown if your type needs type modifiers and the type modifiers have been successfully stored in the metadata. So I think we could elaborate on this a bit.
Regards, Steve.
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-10-11 05:37:07 | Missing deconstruct_array_builtin usage |
Previous Message | jian he | 2024-10-11 05:12:40 | Re: general purpose array_sort |