[postgis-devel] Does changing deserialized data should change stored data?

[Nicklas Avén]

Hallo Interesting
I guess that is what strk means with "based on size", that it is sometimes copied and sometimes not depending on size. To me the connection between what is written on disk and what is just in RAM is beyond what I know and understand. Is there any recommended reading? I mean if the data is not copied, is the memory-address in the pointers then actually pointing to the disk? But it must have space allocated in RAM too, to keep order of the addresse, or ....? Sorry for beginners questions. Thanks Nicklas   
2010-07-29 Pierre Racine wrote:

Thanks,
>
>I tried PG_DETOAST_DATUM_COPY and it fixes the problem however this does not explain why, when using PG_DETOAST_DATUM, sometimes the stored data is edited and sometimes it is not?
>
>Pierre
>
>>-----Original Message-----
>>From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
>>bounces at postgis.refractions.net] On Behalf Of strk
>>Sent: 29 juillet 2010 13:26
>>To: PostGIS Development Discussion
>>Subject: Re: [postgis-devel] Does changing deserialized data should change stored data?
>>
>>On Wed, Jul 28, 2010 at 05:33:27PM -0400, Pierre Racine wrote:
>>
>>> Anybody have an idea why changing the deserialized data actually change the stored data?
>>
>>PG_DETOAST_DATUM copies or not based on size.
>>PG_DETOAST_DATUM_COPY (or similar) forces the copy.
>>
>>--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
>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100729/c852ce3b/attachment.html>