Opened 14 years ago

Closed 11 years ago

#484 closed task (fixed)

[raster] using old style 1.3 syntax and other arcane stuff

Reported by: robe Owned by: pracine
Priority: low Milestone: PostGIS 2.1.0
Component: raster Version: master
Keywords: Cc:


This I'm not sure you want to change just yet and I forget why we had this convention in 1.3. I think it was to support older PostgreSQL installs like 8.1.

I see in your function you have

CREATEFUNCTION st_convexhull(raster)
    AS 'MODULE_PATHNAME','RASTER_convex_hull'

We do now (though I guess you may want to leave costs out if you want 8.2 users to be able to use it)

	RETURNS geometry
	AS 'MODULE_PATHNAME','convexhull'
	COST 100;

On a side note, I see you have inherited our bad habits of not naming the variables going into input. This was done a long time ago I think pre 8.0 before it was okay to put names of variables in the input. Probably not too worthwhile changing now except its confusing reading it when you see integer that that goes to band number or float8 is x etc. Again postgis files are more guilty of this atrocity.

Also you are not always using $ quoting syntax which is much easier to read and has been supported since PostgreSQL 8.0. Admittedly the whole PostGIS code sql file is guilty of this atrocity and worse so so can't complain too much.

Just thought I'd butt my nose in :)

Change History (13)

comment:1 by robe, 14 years ago

Summary: using old style 1.3 syntax and other arcane stuff[wktraster] using old style 1.3 syntax and other arcane stuff

comment:2 by pracine, 14 years ago

So many things here:

1) Replace "CREATEFUNCTION" with "CREATE OR REPLACE FUNCTION". Actually all the macros defined at the beginning of the file with their real values.

2) Lower case the function names. I checked the PostGIS file and there is a mix of camel case and lowercase names. What to do when?

3) Add a cost. Again I checked the PostGIS file and there is a mix of with and without cost. What to do when?

4) Name the input variables.

5) Use $$ instead of ' to delimitate code.

comment:3 by pracine, 14 years ago

1 and 4 done…

comment:4 by pracine, 14 years ago

Need more info to do 2, 3 and 5:

2) Is there any rule to camel case the function names? postgis.sql has a mixture of camelcase/lowercase

3) postgis.sql has a mixture of with/without cost. What is the rule?

5) Again what is the rule? Should we blindly replace all ' with $$ in all type of function (C and SQL). All plpgsql functions now use $$.

comment:5 by robe, 14 years ago

2) Its a bit easier to read camel case I think and would also match the documentation which is camel case. In the end it doesn't matter too much since when it gets into PostgreSQL it all ends up being lowercase by PostgreSQL.

3) Not all functions need costing. The ones that take a lot of time that are non-SQL functions should have costing where there are conditions where they may not need to be run. I'm not sure we have any of those at this point. Probably best to just wait off on this. For SQL functions — generally you don't want to cost them since they often get dissolved by the planner into constituent parts.

5) Yes blindly.

comment:6 by pracine, 14 years ago

Milestone: WKTRaster FuturePostGIS 2.0.0

comment:7 by pracine, 14 years ago

Status: newassigned

comment:8 by pracine, 14 years ago

Summary: [wktraster] using old style 1.3 syntax and other arcane stuff[raster] using old style 1.3 syntax and other arcane stuff

comment:9 by jorgearevalo, 14 years ago

2 and 5 done.

3) We need to list the functions that need cost

comment:10 by pracine, 13 years ago

Milestone: PostGIS 2.0.0PostGIS Raster Future

comment:11 by pracine, 12 years ago

Milestone: PostGIS Raster FuturePostGIS Future

comment:12 by pracine, 11 years ago

In the "Closing very old ones" series, I guess we can close this one too?

comment:13 by Bborie Park, 11 years ago

Milestone: PostGIS FuturePostGIS 2.1.0
Resolution: fixed
Status: assignedclosed

Might as well close this. Everything is done except costs but that requires significant real world testing. Something objective would be nice…

Note: See TracTickets for help on using tickets.