Thread: Re: Problem trying to implement version 3.0 of the PostgreSQL protocol
Re: Problem trying to implement version 3.0 of the PostgreSQL protocol
From
Carlos Guzman Alvarez
Date:
Hello: > Sounds like you are sending junk following the Parse message. You are right thanks very much, but now i have another problem, i don't get response from the postgresql server, hummm this is what i'm sending for test: Byte1 ('P') Int32 (40) String ('') String ('SELECT * FROM public.test_table') Int16 (0) The buffer is anything like this (without commas): 40,0,0,0,40,0,83,69,76,69,67,84,32,42,32,70,82,79,77,32,32,112,117,98,108,105,99,46,116,101,115,116,95,116,97,98,108,101,0,0,0 Any idea ?? -- Best regards Carlos Guzmán Álvarez Vigo-España "No tengo dones especiales.Sólo soy apasionadamente curioso" Albert Einstein, científico.
Hello: > Your Parse message looks fine, but the server will not actually send its > ParseComplete response until you send a Sync or Flush message. The idea > is that Parse is usually going to be part of a series of operations, and > you don't want a separate network packet coming back for each operation > in the series. When you do want to see the results of an operation > before you issue the next one, you can issue either Flush (just forces > out the pending messages) or Sync (which does all the stuff that was > formerly done at the end of a Query message). > > Error messages do get flushed out immediately, which is why you were > able to see the response in the other case. Thanks very much it's working well now :D -- Best regards Carlos Guzmán Álvarez Vigo-Spain "No tengo dones especiales.Sólo soy apasionadamente curioso" Albert Einstein, científico.
Carlos Guzman Alvarez <carlosga@telefonica.net> writes: > You are right thanks very much, but now i have another problem, i don't > get response from the postgresql server, hummm this is what i'm sending > for test: Your Parse message looks fine, but the server will not actually send its ParseComplete response until you send a Sync or Flush message. The idea is that Parse is usually going to be part of a series of operations, and you don't want a separate network packet coming back for each operation in the series. When you do want to see the results of an operation before you issue the next one, you can issue either Flush (just forces out the pending messages) or Sync (which does all the stuff that was formerly done at the end of a Query message). Error messages do get flushed out immediately, which is why you were able to see the response in the other case. regards, tom lane