PostGIS Bug 1587 (was Release Candidate 3)

[Umberto Nicoletti]

For postgis there is a msPOSTGISLayerOpen function and the per layer
initialization of byte order is done there. After that the byte order
is not modified anymore.

Regards,
Umberto

On 1/19/06, Jerry Pisk <jerry.pisk at gmail.com> wrote:
> I wouldn't say misgivings, the code will work either way. The per
> layer code is arguably cleaner even though it's less efficient. But
> there really should be something like LayerInitialize (is there?) that
> will be called when each layer type is first loaded/instantiated,
> where layers can put their initialization code. For PostGIS this
> should be in there.
>
> Jerry
>
> On 1/19/06, Sean Gillies <sgillies at frii.com> wrote:
> > You're right. I'll back out the commit if you have misgivings about it.
> >
> > Sean
> >
> > On Jan 19, 2006, at 10:35 AM, Jerry Pisk wrote:
> >
> > > This is the client machine bit order, is there really a need to store
> > > it locally for each layer? You really only need to find a way to
> > > initialize the variable before any PostGIS layers are open. Even the
> > > existing code would work fine, there will be multiple writes to the
> > > global variable but they will all write the exact same value to it so
> > > it would not matter in which order they come in relation to reads from
> > > it.
> > >
> > > Jerry
> > >
> > > On 1/19/06, Umberto Nicoletti <umberto.nicoletti at gmail.com> wrote:
> > >> A big thanks from Italy!
> > >> So is it gonna make it for 4.8?
> > >>
> > >> Regards,
> > >> Umberto
> > >>
> > >> On 1/19/06, Sean Gillies <sgillies at frii.com> wrote:
> > >>> I just applied Umberto's patch to 4.8 and python/tests/cases/
> > >>> pgtest.py runs just fine. Without this patch, it is possible that
> > >>> users could get into trouble connecting to separate databases from
> > >>> the same map if byte order differs between the DB platforms.
> > >>>
> > >>> Sean
> > >>>
> > >>> On Jan 19, 2006, at 8:10 AM, Steve Lime wrote:
> > >>>
> > >>>> I see no one from Refractions has commented one way or the other.
> > >>>> It would =3D
> > >>>> be nice to get Paul or one of his technical folks to at least bless
> > >>>> the =3D
> > >>>> patch before modifying their module. I think someone from that
> > >>>> group still =3D
> > >>>> hangs out here occationally...
> > >>>>
> > >>>> Steve
> > >>>>
> > >>>>>>> Umberto Nicoletti <umberto.nicoletti at GMAIL.COM> 01/19/06 8:20 AM
> > >>>>>>>>>>
> > >>>> Hi,
> > >>>> do you think this bug could be fixed before 4.8 gets out?
> > >>>>
> > >>>> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=3D3D1587
> > >>>>
> > >>>> It's been there for a month and it looks like a trivial patch to
> > >>>> me. =
> > > I
> > >>>> have tested the patch on 4.6.2.
> > >>>>
> > >>>> Best regards,
> > >>>> Umberto
> > >>>>
> > >>>
> > >>
> >
> > ---
> > Sean Gillies
> > sgillies at frii dot com
> > http://zcologia.com/news
> >
>