[postgis-devel] RFC3

[Paul Ramsey]

On Wed, Jun 10, 2009 at 4:17 AM, Paragon Corporation<lr at pcorp.us> wrote:
> + 0.5
>
> I guess my concern is mostly upgrade.  Are you planning to do this for 1.4?
> I guess as far as upgrade concerns and maybe you have thought about this
> already.  Isn't it going to be difficult to get rid of things like
> st_geometry_overlap
> If they are used in operator definitions.

*sigh* You're right, the fact that many of the system st_* variants
that I hate, and want to remove, are underneath operators and types
makes it impossible to get rid of them cleanly without losing soft
upgrade.  I guess I will just have to move this to 2.0, when
dump/restore will be mandatory.

P

> I would prefer if these were marked RENAME to and for UPGRADE we would use a
> RENAME, but that doesn't seem to be an option since we have the renamed
> names already present (UNLESS we use totally different names).
>
> Makes me wonder if we should have a plpgsql function as part of UPGRADE as
> it would vary depending on how people were upgrading in the past if these
> operator functions we are dropping are or are not in use so we'd need to put
> in a lot of conditional checks like if in use in OPERATORS RENAME them and
> if not drop them.
>
> Thanks,
> Regina
>
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
> Cave-Ayland
> Sent: Wednesday, June 10, 2009 4:56 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] RFC3
>
> Paul Ramsey wrote:
>
>> I'd like to bring this to a vote. I have not touched the naming of
>> longxact functions on purpose, because I think that's a separate
>> discussion. I'm willing to have that discussion, but I don't want it
>> to stop doing the RFC3 change.
>>
>> http://trac.osgeo.org/postgis/ticket/195
>
> The only thing I noticed was the name of the GiST functions, e.g.
> postgis_gist_compress(). Given that we hope to have a geography type at some
> point, perhaps we should consider postgis_gist_geometry_compress() etc...
>
> Other than that, +1 from me as it makes things seem a lot tidier.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius
> Corporation plc - control through freedom http://www.siriusit.co.uk
> t: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>