Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1427 closed defect (fixed)

totopogeom regress failure on 9.1

Reported by: robe Owned by: strk
Priority: medium Milestone: PostGIS 2.0.0
Component: topology Version: master
Keywords: Cc:

Description

I'm getting:

ERROR:  column reference "layer_id" is ambiguous at character 323

I think its the plpgsql you are using with the way they changed the checking on what takes precedence in later versions to prevent unintentional side-effects.

See attached

Attachments (1)

topology_regress_91_totopogeom.zip (2.7 KB ) - added by robe 12 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 by strk, 12 years ago

Any idea on how to fully-qualify parameter names ?

comment:2 by robe, 12 years ago

I usually try to avoid naming the parameters the same as column names to avoid this issue (that's one thing I do like better about SQL Server TransactSQL is you have to put an @ in front) — which is why for my user functions I always do param_.. so I always avoid the trap. That doesn't work too well for a name to expose.

Anyrate you are violating your own model. I think your input argument should be named alayer. To follow your anedge, atopology (toponame) etc. that is already well documented in the docs.

e.g. like you have here: http://www.postgis.org/documentation/manual-svn/ST_AddIsoEdge.html

and your argument names should agree with what you have documented since 9.0+ people in theory (why they would I don't know except to be annoyingly descriptive), can use named arg calling e.g.

SELECT ST_AddIsoEdge(toponame := 'mytopo', apoint := ST_Point(1,2) ...);

comment:3 by robe, 12 years ago

Hmm well I guess layer you are in the habit of calling layer_id like here: http://www.postgis.org/documentation/manual-svn/CreateTopoGeom.html

But it isn't too late to change yet (we have one more day to be somewhat reckless) — except we will need to implement a drop functions feature for you to allow this.

comment:4 by strk, 12 years ago

Agreed on 'alayer' naming. Do we really need a DROP for changing parameter names ?

comment:5 by robe, 12 years ago

Yes unfortunately. Otherwise you get some stupid message that argument names have changed and you have to do a drop (when you try to do a CREATE OR REPLACE). If however you go from unnamed to named, you can do a CREATE OR REPLACE (presumably because no one could have been using named args). I think this drop replace requirement came in 9.0 at the advent of allow call by name.

The only reason I can think they did that is that if you are changing the name of input arguments that people may have been using and they were using named argument calling, you are essentially changing the user API and risk breaking their applications.

comment:6 by strk, 12 years ago

Resolution: fixed
Status: newclosed

r8660 should fix this. Note that with 8.4 I didn't need a DROP to upgrade.

comment:7 by robe, 12 years ago

confirmed for 9.0 you need drop: get this error:

psql:totopogeom.sql:109: ERROR:  cannot change name of input parameter "geom"
HINT:  Use DROP FUNCTION first.

I'll open a separate ticket to put in a drop functions sql to fix these kind of things similar to what we have for raster and postgis which will get tacked on to upgrade minor script.

Note: See TracTickets for help on using tickets.