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!
