aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/libpq
Commit message (Collapse)AuthorAge
* Re-include pqsignal() in libpq.Tom Lane2013-03-17
| | | | | | | | We need this in non-ENABLE_THREAD_SAFETY builds, and also to satisfy the exports.txt entry; while it might be a good idea to remove the latter, I'm hesitant to do so except in the context of an intentional ABI break. At least we don't have a separately maintained source file for it anymore.
* Move pqsignal() to libpgport.Tom Lane2013-03-17
| | | | | | | | | We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
* Provide database object names as separate fields in error messages.Tom Lane2013-01-29
| | | | | | | | | | | | | | | | | | This patch addresses the problem that applications currently have to extract object names from possibly-localized textual error messages, if they want to know for example which index caused a UNIQUE_VIOLATION failure. It adds new error message fields to the wire protocol, which can carry the name of a table, table column, data type, or constraint associated with the error. (Since the protocol spec has always instructed clients to ignore unrecognized field types, this should not create any compatibility problem.) Support for providing these new fields has been added to just a limited set of error reports (mainly, those in the "integrity constraint violation" SQLSTATE class), but we will doubtless add them to more calls in future. Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with additional hacking by Tom Lane.
* pg_isreadyRobert Haas2013-01-23
| | | | | | | New command-line utility to test whether a server is ready to accept connections. Phil Sorber, reviewed by Michael Paquier and Peter Eisentraut
* Fix one-byte buffer overrun in PQprintTuples().Tom Lane2013-01-20
| | | | | | | | | | This bug goes back to the original Postgres95 sources. Its significance to modern PG versions is marginal, since we have not used PQprintTuples() internally in a very long time, and it doesn't seem to have ever been documented either. Still, it *is* exposed to client apps, so somebody out there might possibly be using it. Xi Wang
* Update copyrights for 2013Bruce Momjian2013-01-01
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Allow a streaming replication standby to follow a timeline switch.Heikki Linnakangas2012-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, streaming replication would refuse to start replicating if the timeline in the primary doesn't exactly match the standby. The situation where it doesn't match is when you have a master, and two standbys, and you promote one of the standbys to become new master. Promoting bumps up the timeline ID, and after that bump, the other standby would refuse to continue. There's significantly more timeline related logic in streaming replication now. First of all, when a standby connects to primary, it will ask the primary for any timeline history files that are missing from the standby. The missing files are sent using a new replication command TIMELINE_HISTORY, and stored in standby's pg_xlog directory. Using the timeline history files, the standby can follow the latest timeline present in the primary (recovery_target_timeline='latest'), just as it can follow new timelines appearing in an archive directory. START_REPLICATION now takes a TIMELINE parameter, to specify exactly which timeline to stream WAL from. This allows the standby to request the primary to send over WAL that precedes the promotion. The replication protocol is changed slightly (in a backwards-compatible way although there's little hope of streaming replication working across major versions anyway), to allow replication to stop when the end of timeline reached, putting the walsender back into accepting a replication command. Many thanks to Amit Kapila for testing and reviewing various versions of this patch.
* Add libpq function PQconninfo()Magnus Hagander2012-11-30
| | | | | | | | | | | This allows a caller to get back the exact conninfo array that was used to create a connection, including parameters read from the environment. In doing this, restructure how options are copied from the conninfo to the actual connection. Zoltan Boszormenyi and Magnus Hagander
* Produce a more useful error message for over-length Unix socket paths.Tom Lane2012-11-29
| | | | | | | | | | | | | | The length of a socket path name is constrained by the size of struct sockaddr_un, and there's not a lot we can do about it since that is a kernel API. However, it would be a good thing if we produced an intelligible error message when the user specifies a socket path that's too long --- and getaddrinfo's standard API is too impoverished to do this in the natural way. So insert explicit tests at the places where we construct a socket path name. Now you'll get an error that makes sense and even tells you what the limit is, rather than something generic like "Non-recoverable failure in name resolution". Per trouble report from Jeremy Drake and a fix idea from Andrew Dunstan.
* Fix lo_import and lo_export to return useful error messages more often.Tom Lane2012-10-08
| | | | | | | | | I found that these functions tend to return -1 while leaving an empty error message string in the PGconn, if they suffer some kind of I/O error on the file. The reason is that lo_close, which thinks it's executed a perfectly fine SQL command, clears the errorMessage. The minimum-change workaround is to reorder operations here so that we don't fill the errorMessage until after lo_close.
* Fix lo_read, lo_write, lo_truncate to cope with "size_t" length parameters.Tom Lane2012-10-08
| | | | | | | | | | | | | libpq defines these functions as accepting "size_t" lengths ... but the underlying backend functions expect signed int32 length parameters, and so will misinterpret any value exceeding INT_MAX. Fix the libpq side to throw error rather than possibly doing something unexpected. This is a bug of long standing, but I doubt it's worth back-patching. The problem is really pretty academic anyway with lo_read/lo_write, since any caller expecting sane behavior would have to have provided a multi-gigabyte buffer. It's slightly more pressing with lo_truncate, but still we haven't supported large objects over 2GB until now.
* Code review for 64-bit-large-object patch.Tom Lane2012-10-08
| | | | | | | Fix broken-on-bigendian-machines byte-swapping functions, add missed update of alternate regression expected file, improve error reporting, remove some unnecessary code, sync testlo64.c with current testlo.c (it seems to have been cloned from a very old copy of that), assorted cosmetic improvements.
* Autoconfiscate selection of 64-bit int type for 64-bit large object API.Tom Lane2012-10-07
| | | | | | | | | | | | Get rid of the fundamentally indefensible assumption that "long long int" exists and is exactly 64 bits wide on every platform Postgres runs on. Instead let the configure script select the type to use for "pg_int64". This is a bit of a pain in the rear since we do not want to pollute client namespace with all the random symbols that pg_config.h defines; instead we have to create a separate generated header file, "pg_config_ext.h". But now that the infrastructure is there, we might have the ability to add some other stuff that's long been wanting in this area.
* Fix compiling errors on Windows platform. Fix wrong usage ofTatsuo Ishii2012-10-07
| | | | | INT64CONST macro. Fix lo_hton64 and lo_ntoh64 not to use int32_t and uint32_t.
* Add API for 64-bit large object access. Now users can access up toTatsuo Ishii2012-10-07
| | | | | | | | | | | | 4TB large objects (standard 8KB BLCKSZ case). For this purpose new libpq API lo_lseek64, lo_tell64 and lo_truncate64 are added. Also corresponding new backend functions lo_lseek64, lo_tell64 and lo_truncate64 are added. inv_api.c is changed to handle 64-bit offsets. Patch contributed by Nozomi Anzai (backend side) and Yugo Nagata (frontend side, docs, regression tests and example program). Reviewed by Kohei Kaigai. Committed by Tatsuo Ishii with minor editings.
* libpq: Add missing directory to installdirs targetPeter Eisentraut2012-09-17
| | | | It prevented the libpq directory from being installable by itself.
* Centralize libpq's low-level code for dropping a connection.Tom Lane2012-09-07
| | | | | | | | | | | | | | Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview.
* libpq: Fix memory leak in URI parserPeter Eisentraut2012-08-23
| | | | | | When an invalid query parameter is reported, some memory leaks. found by Coverity
* Add runtime checks for number of query parameters passed to libpq functions.Heikki Linnakangas2012-08-13
| | | | | | | | | | | The maximum number of parameters supported by the FE/BE protocol is 65535, as it's transmitted as a 16-bit unsigned integer. However, the nParams arguments to libpq functions are all of type 'int'. We can't change the signature of libpq functions, but a simple bounds check is in order to make it more clear what's going wrong if you try to pass more than 65535 parameters. Per complaint from Jim Vanns.
* Replace libpq's "row processor" API with a "single row" mode.Tom Lane2012-08-02
| | | | | | | | | | | | | | | | | | | | | After taking awhile to digest the row-processor feature that was added to libpq in commit 92785dac2ee7026948962cd61c4cd84a2d052772, we've concluded it is over-complicated and too hard to use. Leave the core infrastructure changes in place (that is, there's still a row processor function inside libpq), but remove the exposed API pieces, and instead provide a "single row" mode switch that causes PQgetResult to return one row at a time in separate PGresult objects. This approach incurs more overhead than proper use of a row processor callback would, since construction of a PGresult per row adds extra cycles. However, it is far easier to use and harder to break. The single-row mode still affords applications the primary benefit that the row processor API was meant to provide, namely not having to accumulate large result sets in memory before processing them. Preliminary testing suggests that we can probably buy back most of the extra cycles by micro-optimizing construction of the extra results, but that task will be left for another day. Marko Kreen
* perltidy adjustments to new fileAlvaro Herrera2012-07-10
|
* Convert libpq regress script to PerlAlvaro Herrera2012-07-06
| | | | This should ease its use on the Windows build environment.
* Update libpq test expected outputAlvaro Herrera2012-07-06
| | | | | Commit 2b443063 changed wording for some of the error messages, but neglected updating the regress output to match.
* Assorted message style improvementsPeter Eisentraut2012-07-02
|
* Stamp library minor versions for 9.3.Tom Lane2012-06-13
| | | | | | This includes fixing the MSVC copy of ecpg/preproc's version info, which seems to have been overlooked repeatedly. Can't we fix that so there are not two copies??
* Stamp HEAD as 9.3devel.Tom Lane2012-06-13
| | | | Let the hacking begin ...
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-10
| | | | commit-fest.
* When using libpq URI syntax, error out on invalid parameter names.Robert Haas2012-06-08
| | | | Dan Farina
* libpq: URI parsing fixesPeter Eisentraut2012-05-28
| | | | | | | | | | | | | | | Drop special handling of host component with slashes to mean Unix-domain socket. Specify it as separate parameter or using percent-encoding now. Allow omitting username, password, and port even if the corresponding designators are present in URI. Handle percent-encoding in query parameter keywords. Alex Shulgin some documentation improvements by myself
* libpq: Add missing file to GETTEXT_FILES listPeter Eisentraut2012-05-21
| | | | | | For the record, fe-print.c is also missing, but it's sort of deprecated, and the string internationalization there has some issues, and it doesn't seem worth fixing that. So let's leave that out.
* Remove whitespace from end of linesPeter Eisentraut2012-05-15
| | | | pgindent and perltidy should clean up the rest.
* Lots of doc corrections.Robert Haas2012-04-23
| | | | Josh Kupershmidt
* Accept postgres:// URIs in libpq connection functionsAlvaro Herrera2012-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
* Stamp libraries versions for 9.2 (better late than never).Bruce Momjian2012-04-07
|
* Add a "row processor" API to libpq for better handling of large results.Tom Lane2012-04-04
| | | | | | | | | | | Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
* Refactor to eliminate duplicate copies of conninfo default-finding code.Tom Lane2012-03-22
| | | | Alex Shulgin, lightly edited by me
* libpq: Fix minor memory leaksPeter Eisentraut2012-03-16
| | | | | | | | When using connection info arrays with a conninfo string in the dbname slot, some memory would be leaked if an error occurred while processing the following array slots. found by Coverity
* libpq: Fix memory leakPeter Eisentraut2012-03-07
| | | | | | If a client encoding is specified as a connection parameter (or environment variable), internal storage allocated for it would never be freed.
* libpq: Small code clarification, and avoid casting away constPeter Eisentraut2012-03-06
|
* Remove arbitrary limitation on length of common name in SSL certificates.Tom Lane2012-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both libpq and the backend would truncate a common name extracted from a certificate at 32 bytes. Replace that fixed-size buffer with dynamically allocated string so that there is no hard limit. While at it, remove the code for extracting peer_dn, which we weren't using for anything; and don't bother to store peer_cn longer than we need it in libpq. This limit was not so terribly unreasonable when the code was written, because we weren't using the result for anything critical, just logging it. But now that there are options for checking the common name against the server host name (in libpq) or using it as the user's name (in the server), this could result in undesirable failures. In the worst case it even seems possible to spoof a server name or user name, if the correct name is exactly 32 bytes and the attacker can persuade a trusted CA to issue a certificate in which that string is a prefix of the certificate's common name. (To exploit this for a server name, he'd also have to send the connection astray via phony DNS data or some such.) The case that this is a realistic security threat is a bit thin, but nonetheless we'll treat it as one. Back-patch to 8.4. Older releases contain the faulty code, but it's not a security problem because the common name wasn't used for anything interesting. Reported and patched by Heikki Linnakangas Security: CVE-2012-0867
* fe-misc.c depends on pg_config_paths.hAlvaro Herrera2012-02-06
| | | | | | Declare this in Makefile to avoid failures in parallel compiles. Author: Lionel Elie Mamane
* Properly free the sslcompression field in PGconnMagnus Hagander2012-02-01
| | | | Marko Kreen
* Use abort() instead of exit() to abort library functionsPeter Eisentraut2012-01-30
| | | | | | | | | | In some hopeless situations, certain library functions in libpq and libpgport quit the program. Use abort() for that instead of exit(), so we don't interfere with the normal exit codes the program might use, we clearly signal the abnormal termination, and the caller has a chance of catching the termination. This was originally pointed out by Debian's Lintian program.
* Update copyright notices for year 2012.Bruce Momjian2012-01-01
|
* Standardize treatment of strcmp() return valuePeter Eisentraut2011-12-27
| | | | | Always compare the return value to 0, don't use cute tricks like if (!strcmp(...)).
* Don't forget to de-escape the password field in .pgpass.Robert Haas2011-12-22
| | | | | | | | | This has been broken just about forever (or more specifically, commit 7f4981f4af1700456f98ac3f2b2d84959919ec81) and nobody noticed until Richard Huxton reported it recently. Analysis and fix by Ross Reedstrom, although I didn't use his patch. This doesn't seem important enough to back-patch and is mildly backward incompatible, so I'm just doing this in master.
* Enable compiling with the mingw-w64 32 bit compiler.Andrew Dunstan2011-12-10
| | | | | | | Original patch by Lars Kanis, reviewed by Nishiyama Tomoaki and tweaked some by me. This compiler, or at least the latest version of it, is currently broken, and only passes the regression tests if built with -O0.
* Treat ENOTDIR as ENOENT when looking for client certificate fileMagnus Hagander2011-12-03
| | | | | | | | This makes it possible to use a libpq app with home directory set to /dev/null, for example - treating it the same as if the file doesn't exist (which it doesn't). Per bug #6302, reported by Diego Elio Petteno
* Add libpq connection option to disable SSL compressionMagnus Hagander2011-11-28
| | | | | | | This can be used to remove the overhead of SSL compression on fast networks. Laurenz Albe
* Suppress remaining -Waddress warnings from recent gcc versions.Tom Lane2011-10-18
| | | | Still an exercise in satisfying pedants.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-24 16:01:49 +0000