Describe the bug
PostgresMeta.functions.retrieve({ schema, name, args: [] }) is supposed to select the zero-argument overload of a function. When the name is overloaded, the empty args array currently skips the proargtypes filter, so the query returns an arbitrary overload (data[0]).
functions.create() calls retrieve() after creating the function, so creating a zero-argument overload of an existing name can also return the wrong function.
To Reproduce
Using the fixtures in test/db/00-init.sql:
create or replace function public.polymorphic_function_with_no_params_or_unnamed() returns int language sql as 'SELECT 1';
create or replace function public.polymorphic_function_with_no_params_or_unnamed(bool) returns int language sql as 'SELECT 2';
create or replace function public.polymorphic_function_with_no_params_or_unnamed(text) returns text language sql as $$ SELECT 'foo' $$;
await pgMeta.functions.retrieve({
schema: 'public',
name: 'polymorphic_function_with_no_params_or_unnamed',
args: [],
})
Expected behavior
The zero-argument overload is returned (argument_types === '', return_type === 'integer').
If no zero-argument overload exists, retrieve should return the existing "cannot find function" error.
Actual behavior
A different overload is returned. On the test fixtures this is the text overload (argument_types === 'text').
Root cause
In FUNCTIONS_SQL, an empty args array takes the args.length > 0 false branch and emits no p.proargtypes predicate. The inner "''" comparison for the empty-oidvector case is therefore dead code. retrieve() always passes args (default []), so name-based lookup never filters zero-argument functions.
Additional context
Existing tests only cover args: [] for a uniquely named zero-argument function (function_returning_set_of_rows), which hides the bug.
- Library:
@supabase/postgres-meta
- Branch analyzed:
master (641831e)
Describe the bug
PostgresMeta.functions.retrieve({ schema, name, args: [] })is supposed to select the zero-argument overload of a function. When the name is overloaded, the emptyargsarray currently skips theproargtypesfilter, so the query returns an arbitrary overload (data[0]).functions.create()callsretrieve()after creating the function, so creating a zero-argument overload of an existing name can also return the wrong function.To Reproduce
Using the fixtures in
test/db/00-init.sql:Expected behavior
The zero-argument overload is returned (
argument_types === '',return_type === 'integer').If no zero-argument overload exists, retrieve should return the existing "cannot find function" error.
Actual behavior
A different overload is returned. On the test fixtures this is the
textoverload (argument_types === 'text').Root cause
In
FUNCTIONS_SQL, an emptyargsarray takes theargs.length > 0false branch and emits nop.proargtypespredicate. The inner"''"comparison for the empty-oidvectorcase is therefore dead code.retrieve()always passesargs(default[]), so name-based lookup never filters zero-argument functions.Additional context
Existing tests only cover
args: []for a uniquely named zero-argument function (function_returning_set_of_rows), which hides the bug.@supabase/postgres-metamaster(641831e)