Re: [GENERAL] libpq: PQreset not reconnecting connection, even though server is running

I wrote: > I'm guessing (from "incomplete startup packet") that the connection > created by the new thread never actually succeeded, is that the > problem? Will PQreset only work on a connection that had previously > connected successfully? And as soon as I hit "send" on this email light dawned: t

Re: [GENERAL] libpq confusion

On Wednesday, September 20, 2017 1:47:05 PM EDT Igor Korot wrote: >Thx. >So it is referring to the command not a "command returning no data". ;-) assuming create table t (c int); select c from t; - PQresultStatus(result) == PGRES_TUPLES_OK - PQntuples(result) == number or

Re: [GENERAL] libpq confusion

Thx. So it is referring to the command not a "command returning no data". ;-) On Wed, Sep 20, 2017 at 1:42 PM, John R Pierce wrote: > On 9/20/2017 10:34 AM, Igor Korot wrote: > > >From the documentation: > https://www.postgresql.org/docs/9.1/static/libpq-exec.html > > [quote] > PGRES_COMMAND_OK >

Re: [GENERAL] libpq confusion

On 9/20/2017 10:34 AM, Igor Korot wrote: >From the documentation: https://www.postgresql.org/docs/9.1/static/libpq-exec.html [quote] PGRES_COMMAND_OK Successful completion of a command returning no data. [/quote] No data = no rows, right? from that same page, a bit farther down, clarifying t

Re: [GENERAL] libpq confusion

Hi, John, On Wed, Sep 20, 2017 at 12:02 PM, John R Pierce wrote: > On 9/20/2017 6:30 AM, Igor Korot wrote: > > Hi, guys, > > On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey > wrote: > > How do I properly check if the record exists from libpq? > > Igor, > I use PQntuples() to check the number of .

Re: [GENERAL] libpq confusion

On 9/20/2017 6:30 AM, Igor Korot wrote: Hi, guys, On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey wrote: How do I properly check if the record exists from libpq? Igor, I use PQntuples() to check the number of ... tuples, for > 0 I was actually curious - isn't it what "PGRES_COMMAND_OK" for?

Re: [GENERAL] libpq confusion

>How do I properly check if the record exists from libpq? Igor, I use PQntuples() to check the number of ... tuples, for > 0 Allan __ This e-mail message may contain confidential or legally privileged information and is only f

Re: [GENERAL] libpq confusion

Hi, guys, On Wed, Sep 20, 2017 at 12:20 AM, Allan Harvey wrote: > >>How do I properly check if the record exists from libpq? > > Igor, > I use PQntuples() to check the number of ... tuples, for > 0 I was actually curious - isn't it what "PGRES_COMMAND_OK" for? IIUC, this constant indicates succe

Re: [GENERAL] libpq confusion

2017-09-20 5:36 GMT+02:00 Igor Korot : > Hi, ALL, > > draft=# SELECT 1 FROM abcattbl WHERE abt_tnam = 'leagues'; > ?column? > -- > (0 rows) > > > However running it thru the PQexecParam() I am getting "PGRES_TUPLES_OK" > which means that the such record exist. > That means so this comman

Re: [GENERAL] libpq backwards compatbility

PostgreSQL platforms have been upgraded to 9.6. Or make it a dependency of the application release that the PostgreSQL platform is 9.6. Andy From: Michael Paquier Sent: 03 November 2016 09:35 To: Andy Halsall Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] li

Re: [GENERAL] libpq backwards compatbility

On Wed, Nov 2, 2016 at 11:58 PM, Andy Halsall wrote: > Can we assume that the 9.6 libpq library is backwards compatible with > applications compiled against 9.3 headers? I wouldn't expect to have to > re-compile our application against 9.6 libpq headers and redeploy because > we're not taking adva

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 12:45 PM, Francisco Olarte wrote: > Merlin: > > On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure wrote: >> On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte >> wrote: >>> It is, but handling them is not easy, and you have to deal with things >>> like DoS which are not tri

Re: [GENERAL] libpq heartbeat

r for some reasons? I'll be able to check this next morning. Regards Marcin Od: "Tom Lane" Do: "Francisco Olarte" DW: "depesz" , "Marcin Giedz" , pgsql-general@postgresql.org Wysłane: czwartek, 27 październik 2016 18:32:54 Temat: Re: [GENERAL

Re: [GENERAL] libpq heartbeat

Merlin: On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure wrote: > On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte > wrote: >> It is, but handling them is not easy, and you have to deal with things >> like DoS which are not trivial on the server ( as it is a heavy >> service ). It can be done,

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte wrote: > Merlin: > > On Thu, Oct 27, 2016 at 6:10 PM, Merlin Moncure wrote: >> On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte >> wrote: >>> And I'd like to point libpq sessions does not sound to be the best >>> kind of traffic across a firew

Re: [GENERAL] libpq heartbeat

Tom: On Thu, Oct 27, 2016 at 6:32 PM, Tom Lane wrote: > Francisco Olarte writes: >> Isn't this a server setting, and so going to affect every connection, > Yes, Ok, just checking. > but there are equivalent libpq parameters for firing heartbeat > pings from the client side. Those are per-conn

Re: [GENERAL] libpq heartbeat

Francisco Olarte writes: > On Thu, Oct 27, 2016 at 5:01 PM, hubert depesz lubaczewski > wrote: >> On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: >>> I'm wondering if there is any natural implementation of heartbeats in >>> libpq library? >> check tcp_keepalives_* in postgresql.con

Re: [GENERAL] libpq heartbeat

Merlin: On Thu, Oct 27, 2016 at 6:10 PM, Merlin Moncure wrote: > On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte > wrote: >> And I'd like to point libpq sessions does not sound to be the best >> kind of traffic across a firewall, not a good service / protocol to >> expose. > meh -- it's perf

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 10:01 AM, Francisco Olarte wrote: > And I'd like to point libpq sessions does not sound to be the best > kind of traffic across a firewall, not a good service / protocol to > expose. meh -- it's perfectly fine to expose postgres to the internet as long as you've handled th

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 5:01 PM, hubert depesz lubaczewski wrote: > On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: ... >> I'm wondering if there is any natural implementation of heartbeats in >> libpq library? ... > check tcp_keepalives_* in postgresql.conf Isn't this a server set

Re: [GENERAL] libpq heartbeat

Hi Marcin: On Thu, Oct 27, 2016 at 4:43 PM, Marcin Giedz wrote: > I'm wondering if there is any natural implementation of heartbeats in libpq > library? We've been facing specially in firewall env occasionally session > drops between client and server. Extending session timeout directly on > fire

Re: [GENERAL] libpq heartbeat

On Thu, Oct 27, 2016 at 04:43:55PM +0200, Marcin Giedz wrote: > Hello all > > I'm wondering if there is any natural implementation of heartbeats in > libpq library? We've been facing specially in firewall env > occasionally session drops between client and server. Extending > session timeout dire

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 5:01 PM Adrian Klaver wrote: > On 10/07/2016 07:58 AM, arnaud gaboury wrote: > > > > > > > > > GGGrrrh > > > > --- > > # systemctl restart postgresql > > # su mattermost > > bash-4.3$ psql postgresql://mmuser:XXX@/mattermost? > > psql (9

Re: [GENERAL] Libpq functions & string to obtain connection parameters

arnaud gaboury writes: > OK. Now I know unix user mattermost can connect to mattermost Db via unix > socket. BUT when trying to write this in my URI: > postgresql://mmuser:MyPwd@/mattermost?connect_timeout=10 > I get this from my app : > Failed to ping db err:pq: SSL is not enabled on the server

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 07:58 AM, arnaud gaboury wrote: GGGrrrh --- # systemctl restart postgresql # su mattermost bash-4.3$ psql postgresql://mmuser:XXX@/mattermost? psql (9.5.4) Type "help" for help. mattermost=> \q - O

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 4:42 PM Adrian Klaver wrote: On 10/07/2016 07:28 AM, arnaud gaboury wrote: > > > On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver > wrote: > > On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > > > > > > Honestly not so

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 07:28 AM, arnaud gaboury wrote: On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > offi

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 3:56 PM Adrian Klaver wrote: > On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > > > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > > official doc[0]. > > My postgresql socket is in the usual place: > > /run/postgresql/.s.PGSQL.5432= >

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 06:42 AM, arnaud gaboury wrote: > > > > Honestly not so much, as it is a nearly perfect Copy/past of postgresql > official doc[0]. > My postgresql socket is in the usual place: > /run/postgresql/.s.PGSQL.5432= > So no need to specify it. But for the rest, I am still not sure of m

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On 10/07/2016 06:42 AM, arnaud gaboury wrote: does that help? Honestly not so much, as it is a nearly perfect Copy/past of postgresql official doc[0]. My postgresql socket is in the usual place: /run/postgresql/.s.PGSQL.5432= So no need to specify it. But for the rest, I am still not

Re: [GENERAL] Libpq functions & string to obtain connection parameters

On Fri, Oct 7, 2016 at 3:15 PM Andreas Kretschmer wrote: > arnaud gaboury wrote: > > > I start an app which use a libpq function to read connection params in a > URI. > > Until now, the app was using a tcp connection to connect to postgresql > with > > this URI: > > > > postgres:// > mmuser:mmus

Re: [GENERAL] Libpq functions & string to obtain connection parameters

arnaud gaboury wrote: > I start an app which use a libpq function to read connection params in a URI. > Until now, the app was using a tcp connection to connect to postgresql with > this URI: > > postgres://mmuser:mmuser_password@10.10.10.1:5432/mattermost?sslmode=disable& > connect_timeout=10 >

Re: [GENERAL] libpq: why only one PQsendQuery per connection at a time?

2015-01-04 19:02 GMT+03:00 : > Hello! > Question generally to (libpq) developers. > > According to http://www.postgresql.org/docs/9.4/static/libpq-async.html: > "PQsendQuery cannot be called again (on the same connection) until > PQgetResult > has returned a null pointer, indicating that the comma

Re: [GENERAL] libpq: why only one PQsendQuery per connection at a time?

sftf-2 wrote > So question is why this limitaion exists? > > Why PQgetResult(PGconn *conn) operates on connection, > and not on some unique handler that each "PQsend*" could return. > > Is it limitaion of libpq or architecture of postgresql backend or > backend-frontend protocol? IIUC this is a

Re: [GENERAL] libpq equivalent of jdbc:default:connection

Thanks David! This is what I needed. I figured I was looking in the wrong place. On Thu, Dec 11, 2014 at 10:58 AM, David G Johnston < david.g.johns...@gmail.com> wrote: > Jim McLaughlin wrote > > Hi all, > > > > I am rewriting a pljava procedure in C++ with libpq. This procedure needs > > to acce

Re: [GENERAL] libpq equivalent of jdbc:default:connection

Jim McLaughlin wrote > Hi all, > > I am rewriting a pljava procedure in C++ with libpq. This procedure needs > to access some temp tables that the calling procedure creates and > populates. It seems that the connection created by PQconnectdb creates a > new connection (I have tried all permutation

Re: [GENERAL] libpq: indefinite block on poll during network problems

On Fri, May 30, 2014 at 4:00 PM, Dmitry Samonenko wrote: > I'm troubled with possible 'imperfection' of very simple, yet core feature > - PQexec, which can lead to blocked applications. You believe that the > problem is caused by client design flaw. Okay, fine. Is it possible to mark > this poten

Re: [GENERAL] libpq: indefinite block on poll during network problems

Sorry, my last mail got truncated. I'm starting to like Gmail mobile. On Saturday, May 31, 2014, Dmitry Samonenko wrote: > > >> Though this then begs the question: if the connection comes back up what >> happens in the client? > > > >> Depends on the state of the server. If problem was purely net

Re: [GENERAL] libpq: indefinite block on poll during network problems

On Friday, May 30, 2014, David G Johnston wrote: > Tom Lane-2 wrote > > That argument seems nonsensical from here. If you need HA then you > should > > be using network service monitoring tools, not relying on some random > > libpq client to decide that its connection has been lost. I'm troub

Re: [GENERAL] libpq: indefinite block on poll during network problems

Dmitry Samonenko wrote: > I have an application which uses libpq for interaction with remote PostgreSQL > 9.2.4 server. Clients > and Server nodes are running Linux and connection is established using TCPv4. > The client application > has some small fault-tolerance features, which are activated w

Re: [GENERAL] libpq - lack of support to set the fetch size

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Second, the feature needed to do this without even > using a cursor was added 1.5 years ago (PQsetSingleRowMode). The DBD::Pg > was just not taught how to use it yet. True. And we were hoping for something better, so we can make one request

Re: [GENERAL] libpq - lack of support to set the fetch size

On Mar 12, 2014, at 5:57 AM, matshyeq wrote: > I don't see why? I can't think of any single SQL tool I've been working with > that didn't have this functionality, really. > The principle I find very simple and useful. > There is defined "fetch row size" parameter (each tool calls give its own

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/12/2014 06:05 AM, matshyeq wrote: Don't fully agree with last statement. FETCH is WAY better and more functional than LIMIT. PQsetSingleRowMode() is not meant for partial resultsets, but it can be used if you accept the downsides. Given the 'discretion mode' I'm still not

Re: [GENERAL] libpq - lack of support to set the fetch size

On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen wrote: > On Tue, Mar 11, 2014 at 12:39:12PM +, matshyeq wrote: > > - when using PQsetSingleRowMode() function - does it give an option to > > define how many rows to cache on client's side (like JDBC setFetchSize() > > does) or leaves it at pqli

Re: [GENERAL] libpq - lack of support to set the fetch size

> > > Well, I don't know what "streamed" exactly means here. > > If server pushes sequentially all the data not asking client if ready > to > > receive then that's what the issue is about. > > This problem is handled in kernel's TCP stack - it will slow down > the connection if userspace does not

Re: [GENERAL] libpq - lack of support to set the fetch size

On Wed, Mar 12, 2014 at 10:57:03AM +, matshyeq wrote: > On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen wrote: > > This option would not make sense as you are not "fetching" anything, > > full resultset is being streamed from server over TCP connection. > > Well, I don't know what "streamed" exa

Re: [GENERAL] libpq - lack of support to set the fetch size

On Tue, Mar 11, 2014 at 12:39:12PM +, matshyeq wrote: > - when using PQsetSingleRowMode() function - does it give an option to > define how many rows to cache on client's side (like JDBC setFetchSize() > does) or leaves it at pqlib's discretion? This option would not make sense as you are not

Re: [GENERAL] libpq - lack of support to set the fetch size

Marko, Tom, Adrian, Jeff, Daniel - thank you all for valuable feedback! Two general questions: - when using PQsetSingleRowMode() function - does it give an option to define how many rows to cache on client's side (like JDBC setFetchSize() does) or leaves it at pqlib's discretion? - is it/would

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > The only solution is CURSOR based which I find an awkward low level hack > comparing to elegant option supported by native library. That's not the only solution, even with the current DBD::Pg you could do: $dbh->do("COPY (sql-squery) TO STDOUT"); my $data; while ($dbh->

Re: [GENERAL] libpq - lack of support to set the fetch size

On Sun, Mar 9, 2014 at 6:43 AM, matshyeq wrote: > Hello, > > I've found an issue when tried to implement fetching rows from big table > (2mln rows) in my app. > Basically I don't find an elegant and easy way (other than always use > cursors) to limit the number of rows returned. > This causes my

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq writes: > If 'SingleRowMode' goes row-by-row then again it's not a solution, > especially given that this particular issue applies to rather large row > sets. Perhaps you should actually experiment with that solution instead of rejecting it out of hand. Or at least RTFM about it. It do

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/10/2014 04:51 AM, matshyeq wrote: Albe Laurenz wrote: I would believe the stackoverflow (http://stackoverflow.com/questions/21960121/perl-script-fails-when-selecting-data-from-big-postgresql-table) question referred to explains the issue well. You can retrieve the full result set, not

Re: [GENERAL] libpq - lack of support to set the fetch size

>Albe Laurenz wrote: I would believe the stackoverflow ( http://stackoverflow.com/questions/21960121/perl-script-fails-when-selecting-data-from-big-postgresql-table) question referred to explains the issue well. > You can retrieve the full result set, not an option because of client memory limita

Re: [GENERAL] libpq - lack of support to set the fetch size

Fully agree with Laurenz. LIMIT in some (limited!) cases could be seen as a workaround but it's far from being elegant (what if your end user types the query?) If 'SingleRowMode' goes row-by-row then again it's not a solution, especially given that this particular issue applies to rather large row

Re: [GENERAL] libpq - lack of support to set the fetch size

On Mon, Mar 10, 2014 at 06:58:26AM +, Albe Laurenz wrote: > Daniel Verite wrote: > > matshyeq wrote: > > [ runs out of memory on the client because all results from a large query are > retrieved at once ] > > >> "Unfortunately, this is a limitation in the underlying driver (libpq) > >> rath

Re: [GENERAL] libpq - lack of support to set the fetch size

On 3/9/2014 6:43 AM, matshyeq wrote: Hello, I've found an issue when tried to implement fetching rows from big table (2mln rows) in my app. Basically I don't find an elegant and easy way (other than always use cursors) to limit the number of rows returned. This causes my application to break d

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > Postgresql is there for a good while perceived as one of the best (or just > simply the best!?) > available open source DB solution, so I'm really surprised this functionality > is not yet supported... You can retrieve the full result set, you can retrieve it row by row, you ca

Re: [GENERAL] libpq - lack of support to set the fetch size

Daniel Verite wrote: > matshyeq wrote: [ runs out of memory on the client because all results from a large query are retrieved at once ] >> "Unfortunately, this is a limitation in the underlying driver (libpq) rather >> than DBD::Pg itself. There have been talks over the years of supporting >> t

Re: [GENERAL] libpq - lack of support to set the fetch size

matshyeq wrote: > "Unfortunately, this is a limitation in the underlying driver (libpq) rather > than DBD::Pg itself. There have been talks over the years of supporting > this, but nothing concrete yet. Your best bet would be to ask about this on > the Postgres lists" > > Would you consid

Re: [GENERAL] libpq - lack of support to set the fetch size

On 03/09/2014 06:43 AM, matshyeq wrote: Hello, I've found an issue when tried to implement fetching rows from big table (2mln rows) in my app. Basically I don't find an elegant and easy way (other than always use cursors) to limit the number of rows returned. This causes my application to break

Re: [GENERAL] libpq compatibility

On Tue, Feb 12, 2013 at 10:19 AM, Philipp Kraus wrote: > Hello, > > I'm using PG 9.2.2 with Qt for accessing the server. If I compile Qt with the > 9.2.2 libpg, can I use this libpg also with eg 8.3 ? > So can I use the libpg with earlier Postgres database versions? Yes, you can use the most rec

Re: [GENERAL] Libpq and multithreading

A back-trace would definitely be helpful to analyze the issue. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* On Fri, Jan 18, 2013 at 7:35 PM, A

Re: [GENERAL] Libpq and multithreading

I am sure that I am using seperate threads with seperate connection objects and libpq is compiled to be threadsafe. I get access violation both with ssl and without it (without ssl it seems to be more stable, however afer several hundred connects/disconnects it fails). J. -- Sent via pgsql-ge

Re: [GENERAL] Libpq and multithreading

On Mon, Jan 14, 2013 at 9:57 AM, Asia wrote: > It is not possible because connection is local variable in both thread > functions, no common variables are used. > > I checked that it also crashes without SSL. Two threads connecting to the > same server, different databases. hm, where is your li

Re: [GENERAL] Libpq and multithreading

It is not possible because connection is local variable in both thread functions, no common variables are used. I checked that it also crashes without SSL. Two threads connecting to the same server, different databases. Joanna -- Sent via pgsql-general mailing list (pgsql-general@postgresql.

Re: [GENERAL] Libpq and multithreading

On Mon, Jan 14, 2013 at 8:28 AM, Alban Hertroys wrote: > An access violation means that you're trying to access memory that doesn't > belong to your process. I'm not sure where it's originating, that could be > the server but I suspect the issue is at the client-side. > > You're probably just forg

Re: [GENERAL] Libpq and multithreading

An access violation means that you're trying to access memory that doesn't belong to your process. I'm not sure where it's originating, that could be the server but I suspect the issue is at the client-side. You're probably just forgetting to free memory somewhere. On 14 January 2013 13:50, Asia

Re: [GENERAL] Libpq and multithreading

I am using 2 threads, each declares seperate PGconn conenction object. It connects e.g. 60 times, one connection from one thread, the other connection from the other thread, usually one after each other. And it fails at 61'st connection with access violation. I already tried with PQconnect and P

Re: [GENERAL] Libpq and multithreading

On Fri, Jan 11, 2013 at 04:27:42PM +0100, Asia wrote: > Hello, > > I am trying to use libpq in two threads, the issue is that I am getting > access violation after several successful connections. > Each thread connects to different db and disconnects immediately after making > a conenction. > >

Re: [GENERAL] libpq thread safety

Tom Lane wrote: Mark Morgan Lloyd writes: Do any special precautions need to be taken when PQNotifies is being called, to make sure that nothing else is referencing the handle? It's pretty much the same as any other operation on a PGconn: if there could be more than one thread touching the co

Re: [GENERAL] libpq thread safety

Mark Morgan Lloyd writes: > Do any special precautions need to be taken when PQNotifies is being > called, to make sure that nothing else is referencing the handle? It's pretty much the same as any other operation on a PGconn: if there could be more than one thread touching the connection object

Re: [GENERAL] libpq - prevent automatic reconnect

Chris Angelico wrote: On Thu, Dec 6, 2012 at 5:56 AM, Tom Lane wrote: I suspect this action isn't dropping the TCP connection. It's only equivalent to a momentary glitch in your network connectivity --- and you'd be very unhappy if that caused TCP connections to go down, because networks have

Re: [GENERAL] libpq - prevent automatic reconnect

On Thu, Dec 6, 2012 at 5:56 AM, Tom Lane wrote: > I suspect this action isn't dropping the TCP connection. It's only > equivalent to a momentary glitch in your network connectivity --- and > you'd be very unhappy if that caused TCP connections to go down, because > networks have glitches all the

Re: [GENERAL] libpq - prevent automatic reconnect

icholy writes: > libpq will automatically reconnect if the connection is dropped. No it won't. You'd have to do a PQreset() to make that happen. > auto con = PQconnectdb("info");while (true) {PQclear(PQexec(con, > "SELECT * FROM foo LIMIT 1")); > std::this_thread::sleep_for(std::ch

Re: [GENERAL] libpq

On 12/4/2012 11:15 PM, Philipp Kraus wrote: I would like to build a C program, that can access to a Postgres database and I would like to compile the client myself. I think I need "libpq" for access the database, but I can not download the sources of the driver, becausewww.libpqxx.org seems t

Re: [GENERAL] libpq error message deallocation

thanks for the quick reply! -- View this message in context: http://postgresql.1045698.n5.nabble.com/libpq-error-message-deallocation-tp5735032p5735046.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql

Re: [GENERAL] libpq error message deallocation

2012/12/4 icholy > PQerrorMessage function return char const* > > char const* msg = PQerrorMessage(conn); > > Now since it's const, I don't think I should be deallocating it and I've > never seen that done in any examples. But then, when and how does it get > freed? > > At first I thought it

Re: [GENERAL] libpq - PQsendQuery wait for complete result

Albe Laurenz *EXTERN* wrote > If you have a single SQL statement, you will get only one > PQresult. You get more than one if you send a query string > with more than one statement, e.g. > > PQsendQuery(conn, "SELECT 42; SELECT 'Hello'"); > > would result in two PQresults. > > You can get multip

Re: [GENERAL] libpq - PQsendQuery wait for complete result

icholy wrote: > I'm having problem with libpq's *PQexec* function hanging on intermittent > connections. > After searching around, the solution seems to be to use the asynchronous > functions *PQsendQuery*/*PQgetResult* and implement your own timeout. > > Now the issue I'm facing is that *PQgetRes

Re: [GENERAL] libpq-how to add a schema to search path

Hi Laurenz, Thanks for quick reply. I hope it will help. Will check and revert. Best Regards, dpsmails --- On Wed, 10/10/12, Albe Laurenz wrote: From: Albe Laurenz Subject: RE: [GENERAL] libpq-how to add a schema to search path To: "Divakar Singh *EXTERN*" , pgsql-general@post

Re: [GENERAL] libpq-how to add a schema to search path

Divakar Singh wrote: > While making connection to PGSQL using libpq, is there any option to mention the schema name? > Something similar exists in java, however not sure about libpq. Use the "options" connection parameter, like this: psql "dbname=test user=laurenz port=5432 options='-c search_pat

Re: [GENERAL] Libpq question

zeljko wrote: John Townsend wrote: It appears that some developers (Davart) are by-passing the standard client library, “libpq.dll”, and directly accessing the server using Delphi or FPC. I am not sure of the advantage here. All libpq.dll I'm FPC user and I use libpq.so(.dll,.dylib) via zeosl

Re: [GENERAL] Libpq question

On Mon, May 21, 2012 at 9:54 AM, John Townsend wrote: > On 5/21/2012 7:56 AM, Merlin Moncure wrote: > > On Sun, May 20, 2012 at 2:52 PM, John Townsend > wrote: > > By by-passing the "dll" (or "so" on Linux) library I mean you write function > or procedure calls to the server that is running as a

Re: [GENERAL] Libpq question

On 5/21/2012 7:56 AM, Merlin Moncure wrote: On Sun, May 20, 2012 at 2:52 PM, John Townsend wrote: By by-passing the "dll" (or "so" on Linux) library I mean you write function or procedure calls to the server that is running as a service on Windows. You don't use the library with its 160 export

Re: [GENERAL] Libpq question

Jasen Betts writes: > On 2012-05-16, John Townsend wrote: >> *** So...the question: Is there a good reason why you might want to NOT >> use libpq.dll, and just directly access the server through direct >> function calls? *** > libpq binds you to using NUL terminated C strings, and, no doubt, o

Re: [GENERAL] Libpq question

On Sun, May 20, 2012 at 2:52 PM, John Townsend wrote: > By by-passing the "dll" (or "so" on Linux) library I mean you write function > or procedure calls to the server that is running as a service on Windows. > You don't use the library with its 160 exported functions. You connect > directly to th

Re: [GENERAL] Libpq question

On Mon, May 21, 2012 at 9:05 PM, John Townsend wrote: > I downloaded PIKE. The "PostgreSQL direct network module for Pike", > pgsql.pike (and the other modules), shows how it was done. > > Many thanks for the tip. I rarely step out of Delphi, so I was unaware of > the power and versatility of Pike

Re: [GENERAL] Libpq question

In that case, yes, there are such implementations around. Martijn mentioned a few, and I mentioned the Pike one, all of which do indeed bypass libpq and talk directly to the server. It is, as I understand it, an open and stable protocol, so it's no different from writing a program that connects to

Re: [GENERAL] Libpq question

On 2012-05-16, John Townsend wrote: > *** So...the question: Is there a good reason why you might want to NOT > use libpq.dll, and just directly access the server through direct > function calls? *** libpq binds you to using NUL terminated C strings, and, no doubt, other C idioms. if you do it

Re: [GENERAL] Libpq question

On Mon, May 21, 2012 at 6:12 AM, John R Pierce wrote: > On 05/20/12 12:52 PM, John Townsend wrote: >> >> By by-passing the "dll" (or "so" on Linux) library I mean you write >> function or procedure calls to the server that is running as a service on >> Windows. You don't use the library with its 1

Re: [GENERAL] Libpq question

On 05/20/12 12:52 PM, John Townsend wrote: By by-passing the "dll" (or "so" on Linux) library I mean you write function or procedure calls to the server that is running as a service on Windows. You don't use the library with its 160 exported functions. You connect directly to the server thus sa

Re: [GENERAL] Libpq question

By by-passing the "dll" (or "so" on Linux) library I mean you write function or procedure calls to the server that is running as a service on Windows. You don't use the library with its 160 exported functions. You connect directly to the server thus saving one layer of protocols. To do this, y

Re: [GENERAL] Libpq question

On Sun, May 20, 2012 at 02:51:42PM +0200, zeljko wrote: > John Townsend wrote: > > > It appears that some developers (Davart) are by-passing the standard > > client library, ???libpq.dll???, and directly accessing the server using > > Delphi or FPC. I am not sure of the advantage here. All libpq.d

Re: [GENERAL] Libpq question

John Townsend wrote: > It appears that some developers (Davart) are by-passing the standard > client library, “libpq.dll”, and directly accessing the server using > Delphi or FPC. I am not sure of the advantage here. All libpq.dll I'm FPC user and I use libpq.so(.dll,.dylib) via zeoslib. Those w

Re: [GENERAL] Libpq question

On Wed, May 16, 2012 at 10:21 AM, John Townsend wrote: > It appears that some developers (Davart) are by-passing the standard client > library, “libpq.dll”, and directly accessing the server using Delphi or FPC. > I am not sure of the advantage here. All libpq.dll functions can be called > from De

Re: [GENERAL] Libpq question

On Thu, May 17, 2012 at 1:21 AM, John Townsend wrote: > *** So...the question: Is there a good reason why you might want to NOT use > libpq.dll, and just directly access the server through direct function > calls? *** I don't know what you mean by function calls, but the Pike Postgres module dire

Re: [GENERAL] libpq 8.3 and 8.4 interfaces

On Tue, Oct 11, 2011 at 3:03 PM, salah jubeh wrote: > Hello Bruce, > Nothing is missing,  I was looking for a summary of what has changed in > libpq. But certainly the links are more than helpful. Thanks again for the > quick response > Regards another great place to get a bird's eye view of what

Re: [GENERAL] libpq 8.3 and 8.4 interfaces

@postgresql.org Sent: Tuesday, October 11, 2011 9:55 PM Subject: Re: [GENERAL] libpq 8.3 and 8.4 interfaces John R Pierce wrote: > On 10/11/11 12:42 PM, salah jubeh wrote: > > > > Could someone point me,  where I can find the difference between libpq > > 8.3 and 8.4, I have seen the ne

Re: [GENERAL] libpq 8.3 and 8.4 interfaces

John R Pierce wrote: > On 10/11/11 12:42 PM, salah jubeh wrote: > > > > Could someone point me, where I can find the difference between libpq > > 8.3 and 8.4, I have seen the new features of the 8.4, but I want to > > know about the API interface changes > > open > http://www.postgresql.org/do

Re: [GENERAL] libpq 8.3 and 8.4 interfaces

Thanks for the quick support   Best Regard From: John R Pierce To: pgsql-general@postgresql.org Sent: Tuesday, October 11, 2011 9:52 PM Subject: Re: [GENERAL] libpq 8.3 and 8.4 interfaces On 10/11/11 12:42 PM, salah jubeh wrote: > > Could someone po

  1   2   3   >