Doc of typmod arg perhaps deserves an update

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.

Responses

Browse pgsql-hackers by date

  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