> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
