#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)
Change History (8)
by , 13 years ago
Attachment: | topology_regress_91_totopogeom.zip added |
---|
comment:1 by , 13 years ago
comment:2 by , 13 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 , 13 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 , 13 years ago
Agreed on 'alayer' naming. Do we really need a DROP for changing parameter names ?
comment:5 by , 13 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 , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
r8660 should fix this. Note that with 8.4 I didn't need a DROP to upgrade.
comment:7 by , 13 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.
Any idea on how to fully-qualify parameter names ?