Re: cache problem (v2)

> Is that BEGIN;? If not, this is _not_ one transaction. It's two.
>
Ok
> You're not actually _calling_ the trigger, right? It just happens
> automatically? Also, I don't have the slightest clue how this code=3
> (does not exist) works. AFAICT code=1. So code=3 is never true, no?
>
Yes it's a case study but my trigger consider this possibility.
>
>> Now I have a flat file :
>> 1,150
>> 2,450
>>
>> COPY .... path_to_this_flat_file
>>
>> code=3,qte=450
>> Why ?
>>
>
> Because it's all one transaction, and because there's more than one
> state your variables could resolve to, only one of them actually
> applies is my _guess_. It's hard for me to say with any more detail
> without the code and the schema. Anyway, you have two transactions
> in your first example, it appears. The COPY statement is only one.
>
Ok, but strange for me ... the transaction is a guarantee of visibility
inter process but in the same also ?
If yes it' is possible to change that ? I see on the documentation (yes,
yes I read them :-) ) that the UNCOMMITED_READ are equal to COMMITED
READ in postgres
>
>> Another error also is "duplicate key"
>>
>
> This is a different problem. Where is it coming from? Anyway, you
> have some sort of collision there, as the result I assume of your
> modifications of the data. Does it only happen with the COPY case?
> If so, that's another clue that the trigger function is not doing
> what you think it is.
>
Yes I agree, originally same problem
>
>> I read the documentation from postgres not all. But sufficiently to
>> start a test of a trigger.
>>
>
> But apparently not a successful one ;-) I'm just saying, it seems to
> me that you have a deep misunderstanding of the way transaction scope
> works. I think you need to have another look at that. I also think
> you need to look a little harder at how COPY works as compared to
> INSERT.
>
Yes for me in the same transaction I see my update but is not the case.
But I agree I take more time to understand the transactional part :-)

Regards

Guy