On Thu, Mar 31, 2011 at 11:34 AM, Annamalai Gurusami <annamalai.gurusami@xxxxxxxxx> wrote: > Hi All, > > I would like to know about the best approach to take for providing a merged > model of libpq library. When I say "merged model" it means that the client > and server would be running as a single process. A single client libpq > application can be linked to either the client-server libpq library or > merged libpq library. For more clarity here is a small flow diagram: > > Client Server Model: > > Application -> libpq library (cs) -> TCP/IP network -> libpq (backend) -> > pgsql server > > Merged Model: > > Application -> libpq library (merged) -> pgsql server > > One approach that we are having in mind is to use the SPI interface and > re-implement the libpq APIs. Is there any other better approach? Would it > be possible to implement the client server protocol into an API interface, > without involving the TCP/IP network? > > Your thoughts and suggestions on this would be highly appreciated. One big issue with SPI that need to be aware of is that you have no explicit transaction control Once you are in SPI land, you are in one transaction and one transaction only -- this means all locks are held indefinitely as well as other issues. I don't think fully server side applications are practical until we get stored procedures with explicit transaction control (and once we have them, that's all i'll ever write if given a choice). merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
