On Tue, Nov 4, 2025 at 5:25 AM Jim Jones <[email protected]> wrote:
> Hi Nishant > > On 04/11/2025 11:37, Nishant Sharma wrote: > > Using name as parameter is more user friendly than OID. > > Because users usually do not know the oids. Constructing > > the DDL from the name appears better as it contains a name > > in it. So, no gain in having an OID version of > > pg_get_tablespace_ddl. > > Would you also say that having a pg_tablespace_size(oid) has no benefit? > > I took a look at similar functions, and the only pattern I could > identify is that all of them take an oid parameter. > > pg_tablespace_size: oid and name > pg_tablespace_location: oid > has_tablespace_privilege: oid, name, and text > pg_tablespace_databases: oid > ... > pg_get_tablespace_ddl: name > > I'm definitely not opposed to having just a name parameter, but I > thought it would be worth mentioning. > > Best, Jim > Hello, Jim and Nishant! About having an OID variant: I definitely want to keep the current name-based parameter, and it looks like we all agree on that. The question is if we should additionally have an OID-based variant. I personally see no harm in additionally having an OID-based variant, seeing as it looks like a lot of functions do seem to take an OID. If I understand correctly, many functions take an OID, and Postgres users are supposed to have read the docs ( https://www.postgresql.org/docs/current/datatype-oid.html) to know to cast names to OIDs. So, in terms of following established practice / patterns, an OID-based variant is defensible. Thankfully for people like me (for whom the "just cast the OID to a name" pattern never sunk in after 25 years of using Postgres), I'm glad text/name variants of functions are also a thing in Postgres, as I suspect every time a user has a choice between the two, a user will choose to just provide the name. Let me know what you think! Thanks, Jim, Thanks Nishant for fixing/improving my v2 patch to v3! -Manni
