[postgis-users] AddGeometryColumn() Question

[strk at refractions.net]

On Fri, Jan 06, 2006 at 02:21:03PM -0500, Stephen Woodbridge wrote:
> strk at refractions.net wrote:
> >On Fri, Jan 06, 2006 at 09:54:06AM -0500, Stephen Woodbridge wrote:
..
> >>Does it have the smarts to check if it already exists and continue only 
> >>updating the missing information and constraints?
> >
> >
> >No, it's dumb. I was thinking about this when working on topology support.
> >SQL/MM specs use a "santifier" function for this (read: use existing thing
> >making it a "special" thing), while AddGeometryColumn insists on creating
> >it. 
> >
> >
> >>Would it make sense to make it behave like this? exactly for this purpose?
> >
> >
> >Good question, what other people think ?
> 
> I like the idea of having a SanctifyGeometyColumn() or 
> BlessGeometryColumn() to bless a column that was created via means other 
> than AddGeometryColumn() which is not always the "best" way to create 
> the table.
> 
> I am building a process to delete and reload vendor data on a quarterly 
> basis from a table that has multiple data sets merged into it. We do 
> this by copying an existing production table doing the updates to it 
> then swap it into production.

How are you at pl/pgsql coding ?

It should be pretty simple to make the BlessGeometryColumn() by
taking AddGeometryColumn (the one with most args) and substituting
the column addition code with a check for existance and compatiblity
(is it a geometry column?).

Also, it's probably worth checking for triggers (AddGeometryColumns
always attempts at creating them... could be triggers are already
there on a column to be blessed).

Note finally, that the lwpostgis.sql.in file is preprocessed, so
to take into account all supported version of pgsql (from 7.2 up)
by use of USE_VERSION macro... see the existing code for tips.

--strk;