I am trying to use the following function;
SELECT Assign_vertex_id(\'ways\', 0.00001, \'the_geom\', \'gid\')
but for some reason it is givi
PostgreSQL supports function overloading.
With overloaded functions (like you obviously have), a call with just text literals (and no explicit type casts) can be ambiguous.
Normally, adding explicit type casts to your parameters literals fixes the problem. Arbitrary example:
SELECT my_fuc('foo'::text, 0.001::numeric, 123::int);
In your case, this call is ambiguous:
addGeometryColumn('vertices_tmp', 'the_geom', 4326, 'POINT', 2)
Be aware of these points:
All unquoted identifiers are cast to lower case in Postgres.
addGeometryColumn(...)
is effectively the same as addgeometrycolumn(...)
.
You may need to schema-qualify the function name to make it unambiguous. (Maybe you recently changed the search_path leading to a surprising result.
If you do indeed have overloaded functions (not uncommon), add type casts to make your calls unambiguous.
Defining parameter defaults for overloaded functions can make a previously unique call ambiguous.
I have also encountered this problem and I think the OP may have solved it incorrectly. First, AddGeometryColumn is indeed overloaded. The three prototypes are:
AddGeometryColumn(table_name, column_name, srid, type, dimension,
use_typmod=true)
AddGeometryColumn(schema_name, table_name, column_name, srid, type, dimension, use_typmod=true)
AddGeometryColumn(catalog_name, schema_name, table_name, column_name, srid, type, dimension, use_typmod=true)
In my case, changing the following query:
SELECT AddGeometryColumn('public', 'facilities', 'walk_area', 4326, 'POLYGON', 2);
(which uses the second form) to this:
SELECT AddGeometryColumn('public', 'facilities', 'walk_area', 4326, 'POLYGON', 2, true);
solved the problem.