On Wed, May 08, 2024 at 07:57:55PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Agreed. Another option could be to just annotate the arguments with the
>> parameter names.
>
> At the call sites you mean? Sure, I can do that.
Yes.
--
Nathan Bossart
Amazon Web Services:
Nathan Bossart writes:
> On Wed, May 08, 2024 at 07:42:18PM -0400, Tom Lane wrote:
>> One positive reason for increasing the number of parameters is that
>> that will be a clear API break for any outside callers, if there
>> are any. If I just replace a bool with an enum, such callers might
>>
On Wed, May 08, 2024 at 07:42:18PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Looks reasonable to me. The added test coverage seems particularly
>> valuable. If I really wanted to nitpick, I might complain about the three
>> consecutive Boolean parameters for
Nathan Bossart writes:
> Looks reasonable to me. The added test coverage seems particularly
> valuable. If I really wanted to nitpick, I might complain about the three
> consecutive Boolean parameters for AlterTypeNamespaceInternal(), which
> makes lines like
> +
On Wed, May 08, 2024 at 05:52:31PM -0400, Tom Lane wrote:
> The attached patch fixes up the code and adds a new test to
> the test_extensions module. The fix basically is to skip the
> pg_depend entries for dependent types, assuming that they'll
> get dealt with when we process their parent
I happened to notice that the comment for AlterObjectNamespace_oid
claims that
* ... it doesn't have to deal with certain special cases
* such as not wanting to process array types --- those should never
* be direct members of an extension anyway.
This struck me as probably broken in the wake
