[postgis-devel] Should we start using default args now?

[Paragon Corporation]

That's just the refentry id.  We had to give all raster functions an id of
RT_ST though the functions just starts with ST_ to prevent page conflict
with geometry functions of same name.

Otherwise we'd have to include all the raster same named functions in the
geometry/geography section -- which I know you would REALLY like :)

 BTW:  I've taken the first dip and converted my ST_AsX3D to use optional
arguments -- so now I have just one instead of 2.

Waiting to see how this looks in the docs.  

It looks like I can drop the function after I create the new one, so adding
it in the drop.sql.in.c works.  Well I have to double check on 8.4, 9.0 but
can get away with it in 9.1.

If that works -- are people okay with me getting rid of all those extra
permutations of ST_AsGeoJSON, ST_AsGML etc. that  I've always been eyeing to
remove with bated breath?

It shouldn't break anyones code since I'll make sure to maintain the same
public API.

Then I can attack raster code as well -- if raster folks don't mind me
stepping in their territory.


Thanks,
Regina
-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Tuesday, May 17, 2011 2:03 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Should we start using default args now?

RT_ST?
P

On Tue, May 17, 2011 at 10:41 AM, Paragon Corporation <lr at pcorp.us> wrote:
> I like that.  Though we should start with Bborie's first (which 
> doesn't require drop anything since they are so new)
>
> Many of the raster functions have 4 or 5 protos per function.
>
> So Bborie added about 10 (hmm maybe more but that's as high as I can 
> count) new functions each of which has anywhere from 2-10 
> permutations. -- to add up to a lot.
>
> For example:
> http://www.postgis.org/documentation/manual-svn/RT_ST_AsPNG.html
>
> Great functions by the way :)
>
> So I've been hesitant to document the ST_AsTiff, ST_AsJPEG and all the 
> analytics if we are going to go default args.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of 
> Paul Ramsey
> Sent: Tuesday, May 17, 2011 1:20 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Should we start using default args now?
>
> We can include DROP IF EXISTS at the front of the upgrade scripts 
> (already do that do some extent) to clean out non-defaulted pre-existing
functions.
> P.
>
> On Mon, May 16, 2011 at 11:04 PM, Paragon Corporation <lr at pcorp.us> wrote:
>> No CREATE OR REPLACE would not  replace them.  We would have to drop
them.
>>
>> I was thinking about just new functions like the 100 some odd Bborie 
>> just loaded on us :)
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of 
>> Sandro Santilli
>> Sent: Tuesday, May 17, 2011 2:01 AM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Should we start using default args now?
>>
>> On Tue, May 17, 2011 at 01:01:13AM -0400, Paragon Corporation wrote:
>>> Now that Bborie has unleashed his load of functions; I'm not 
>>> complaining, I did ask for it :)
>>>
>>> I was wondering if maybe we should start using default arguments at 
>>> least for raster.  Now that our minimum is 8.4 for PostGIS 2.0, this 
>>> is now an option.  Does it make sense?
>>
>> If 8.4 supports them, I'm for it. Surely for new functions.
>> Old functions might need more verifications (does CREATE OR REPLACE 
>> replace them ?).
>>
>> --strk;
>>
>>  ()   Free GIS & Flash consultant/developer
>>  /\   http://strk.keybit.net/services.html
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel