aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces
Commit message (Collapse)AuthorAge
* Stamp 9.1.5.REL9_1_5Tom Lane2012-08-14
|
* Translation updatesPeter Eisentraut2012-08-14
|
* Update copyright year in forgotten placesPeter Eisentraut2012-06-19
| | | | found by Stefan Kaltenbrunner
* Stamp 9.1.4.REL9_1_4Tom Lane2012-05-31
|
* Translation updatesPeter Eisentraut2012-05-31
|
* ecpg: Fix off-by-one error in memory copyingPeter Eisentraut2012-03-11
| | | | | | | In a rare case, one byte past the end of memory belonging to the sqlca_t structure would be written to. found by Coverity
* ecpg: Fix rare memory leaksPeter Eisentraut2012-03-11
| | | | found by Coverity
* libpq: Fix memory leakPeter Eisentraut2012-03-11
| | | | | | If a client encoding is specified as a connection parameter (or environment variable), internal storage allocated for it would never be freed.
* Stamp 9.1.3.REL9_1_3Tom Lane2012-02-23
|
* 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
* Translation updatesPeter Eisentraut2012-02-23
|
* Do not use the variable name when defining a varchar structure in ecpg.Michael Meskes2012-02-13
| | | | With a unique counter being added anyway, there is no need anymore to have the variable name listed, too.
* 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
* In ecpg removed old leftover check for given connection name.Michael Meskes2011-12-18
| | | | | | | | Ever since we introduced real prepared statements this should work for different connections. The old solution just emulating prepared statements, though, wasn't able to handle this. Closes: #6309
* Applied another patch by Zoltan to fix memory alignement issues in ecpg's sqldaMichael Meskes2011-12-04
| | | | code.
* 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
* Stamp 9.1.2.REL9_1_2Tom Lane2011-12-01
|
* Translation updatesPeter Eisentraut2011-12-01
|
* Applied Zoltan's patch to correctly align interval and timestamp data in ↵Michael Meskes2011-11-17
| | | | ecpg's sqlda.
* Applied patch by Zoltan to fix copy&paste bug in ecpg's sqlda handling.Michael Meskes2011-11-13
|
* Stamp 9.1.1.REL9_1_1Tom Lane2011-09-22
|
* Translation updatesPeter Eisentraut2011-09-22
|
* Teach the makefile used to build stand-alone libpq on Windows that libpqHeikki Linnakangas2011-09-14
| | | | | needs win32setlocale.c now. The cygwin and MSVC build scripts were changed earlier, but this was neglected. This should fix bug report #6203 by Steve.
* Translation updates for 9.1.0Peter Eisentraut2011-09-08
|
* Add missing format argument to ecpg_log() callPeter Eisentraut2011-09-08
|
* Allow bcc32 and win32 batch files to compile libpq.Bruce Momjian2011-09-07
| | | | | | Backpatch to 9.1. By Hiroshi Saito
* Fix brace indentation of commit 5ad0e899f08136a00f56bf224a6b9729b2f4c69f to ↵Michael Meskes2011-09-02
| | | | fit PostgreSQL style.
* Remove spurious comma. Spotted by Tom.Heikki Linnakangas2011-09-01
|
* libpq compiles various pgport files like ecpg does, and needs similar MakefileHeikki Linnakangas2011-09-01
| | | | | changes for the win32 setlocale() wrapper I put into ecpg, to make it compile on MinGW.
* In ecpglib restore LC_NUMERIC in case of an error.Michael Meskes2011-09-01
|
* Fix MinGW build, broken by my previous patch to add a setlocale() wrapperHeikki Linnakangas2011-09-01
| | | | | | | on Windows. ecpglib doesn't link with libpgport, but picks and compiles the .c files it needs individually. To cope with that, move the setlocale() wrapper from chklocale.c to a separate setlocale.c file, and include that in ecpglib.
* Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.Tom Lane2011-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
* Ensure we discard unread/unsent data when abandoning a connection attempt.Tom Lane2011-08-27
| | | | | | | | | | | | | | | | | There are assorted situations wherein PQconnectPoll() will abandon a connection attempt and try again with different parameters (eg, SSL versus not SSL). However, the code forgot to discard any pending data in libpq's I/O buffers when doing this. In at least one case (server returns E message during SSL negotiation), there is unread input data which bollixes the next connection attempt. I have not checked to see whether this is possible in the other cases where we close the socket and retry, but it seems like a matter of good defensive programming to add explicit buffer-flushing code to all of them. This is one of several issues exposed by Daniel Farina's report of misbehavior after a server-side fork failure. This has been wrong since forever, so back-patch to all supported branches.
* Translation updatesPeter Eisentraut2011-08-17
|
* Fix previous patch so it also works if not USE_SSL (mea culpa).Tom Lane2011-07-24
| | | | | | On balance, the need to cover this case changes my mind in favor of pushing all error-message generation duties into the two fe-secure.c routines. So do it that way.
* Improve libpq's error reporting for SSL failures.Tom Lane2011-07-24
| | | | | | | | | | In many cases, pqsecure_read/pqsecure_write set up useful error messages, which were then overwritten with useless ones by their callers. Fix this by defining the responsibility to set an error message to be entirely that of the lower-level function when using SSL. Back-patch to 8.3; the code is too different in 8.2 to be worth the trouble.
* Use OpenSSL's SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag.Tom Lane2011-07-24
| | | | | | | | | | | | | | | This disables an entirely unnecessary "sanity check" that causes failures in nonblocking mode, because OpenSSL complains if we move or compact the write buffer. The only actual requirement is that we not modify pending data once we've attempted to send it, which we don't. Per testing and research by Martin Pihlak, though this fix is a lot simpler than his patch. I put the same change into the backend, although it's less clear whether it's necessary there. We do use nonblock mode in some situations in streaming replication, so seems best to keep the same behavior in the backend as in libpq. Back-patch to all supported releases.
* Fix PQsetvalue() to avoid possible crash when adding a new tuple.Tom Lane2011-07-21
| | | | | | | | | | | | | | | PQsetvalue unnecessarily duplicated the logic in pqAddTuple, and didn't duplicate it exactly either --- pqAddTuple does not care what is in the tuple-pointer array positions beyond the last valid entry, whereas the code in PQsetvalue assumed such positions would contain NULL. This led to possible crashes if PQsetvalue was applied to a PGresult that had previously been enlarged with pqAddTuple, for instance one built from a server query. Fix by relying on pqAddTuple instead of duplicating logic, and not assuming anything about the contents of res->tuples[res->ntups]. Back-patch to 8.4, where PQsetvalue was introduced. Andrew Chernow
* Adapted expected result for latest change to ecpglib.Michael Meskes2011-07-18
|
* Made ecpglib write double with a precision of 15 digits.Michael Meskes2011-07-18
| | | | Patch originally by Akira Kurosawa <kurosawa-akira@mxc.nes.nec.co.jp>.
* Capitalization fixesPeter Eisentraut2011-06-19
|
* Use single quotes in preference to double quotes for protecting pathnames.Tom Lane2011-06-15
| | | | | | Per recommendation from Peter. Neither choice is bulletproof, but this is the existing style and it does help prevent unexpected environment variable substitution.
* Rework parsing of ConstraintAttributeSpec to improve NOT VALID handling.Tom Lane2011-06-15
| | | | | | | | | | | The initial commit of the ALTER TABLE ADD FOREIGN KEY NOT VALID feature failed to support labeling such constraints as deferrable. The best fix for this seems to be to fold NOT VALID into ConstraintAttributeSpec. That's a bit more general than the documented syntax, but it allows better-targeted syntax error messages. In addition, do some mostly-but-not-entirely-cosmetic code review for the whole NOT VALID patch.
* Fix assorted issues with build and install paths containing spaces.Tom Lane2011-06-14
| | | | | | Apparently there is no buildfarm critter exercising this case after all, because it fails in several places. With this patch, build, install, check-world, and installcheck-world pass for me on OS X.
* Move parse2.pl to parse.plPeter Eisentraut2011-06-14
| | | | We have a SCM, so we don't need to keep old versions of files around.
* Translation updates for 9.1beta2Peter Eisentraut2011-06-09
|
* Pgindent run before 9.1 beta2.Bruce Momjian2011-06-09
|
* Need to list getpeereid.c in .gitignore, too ...Tom Lane2011-06-02
|
* libpq needs its own copy of src/port/getpeereid.Tom Lane2011-06-02
| | | | ... on some platforms, anyway. Per buildfarm.
* Implement getpeereid() as a src/port compatibility function.Tom Lane2011-06-02
| | | | | | | This unifies a bunch of ugly #ifdef's in one place. Per discussion, we only need this where HAVE_UNIX_SOCKETS, so no need to cover Windows. Marko Kreen, some adjustment by Tom Lane
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 15:18:45 +0000