From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Florents Tselai <florents(dot)tselai(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: mention unused_oids script in pg_proc.dat |
Date: | 2025-07-08 23:28:00 |
Message-ID: | aG2pgD3IqCARGiC0@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 08, 2025 at 05:40:39PM +0300, Florents Tselai wrote:
> On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>> +
>>> +Below are some checklists for common scenarios.
>>> +
>>> +## Adding a New Built-in SQL Command
>>> +
>>> +1. Implement the function in C and place it in the appropriate
>> directory under `src` (typically in `src/utils/adt`)
>>> +2. Each function should have a unique integer OID. Run the script
>> `src/include/catalog/unused_oids` to find available ranges.
>>> +3. Add the entry to `pg_proc.dat` following the surrounding
>> conventions.
>>
>> Presumably, if you're developing this kind of thing, you are already
>> reading some other part of the documentation, maybe xfunc.sgml? Do we
>> need to add more information there, or some links?
>
> I agree. Added a link reference to that xfunc-c
I understand Peter's comment that we need something more general than
what your v2-0001 is proposing, the point being that modifying
pg_proc.dat may apply to some concepts, but it's far from being all of
them. If you need to add a new in-core type, or something else to a
different catalog, then you need to be aware of a completely different
.dat file. This set of instructions read as being a bit misleading,
IMO.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Jungwirth | 2025-07-08 23:49:30 | Fix comment in btree_gist--1.8--1.9.sql |
Previous Message | Michael Paquier | 2025-07-08 23:20:31 | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |