aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces
Commit message (Collapse)AuthorAge
* Stamp 9.1.8.REL9_1_8Tom Lane2013-02-04
|
* Translation updatesPeter Eisentraut2013-02-03
|
* Made ecpglib use translated messages.Michael Meskes2013-01-27
| | | | Bug reported and fixed by Chen Huajun <chenhj@cn.fujitsu.com>.
* 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
* Include isinf.o in libecpg if isinf() is not available on the system.Michael Meskes2012-12-04
| | | | Patch done by Jiang Guiqing <jianggq@cn.fujitsu.com>.
* Stamp 9.1.7.REL9_1_7Tom Lane2012-12-03
|
* Translation updatesPeter Eisentraut2012-12-03
|
* 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.
* When processing nested structure pointer variables ecpg always expected anMichael Meskes2012-11-29
| | | | | | array datatype which of course is wrong. Applied patch by Muhammad Usama <m.usama@gmail.com> to fix this.
* 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.
* Fixed test for array boundary.Michael Meskes2012-10-05
| | | | | | Instead of continuing if the next character is not an array boundary get_data() used to continue only on finding a boundary so it was not able to read any element after the first.
* Stamp 9.1.6.REL9_1_6Tom Lane2012-09-19
|
* Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug.Tom Lane2012-09-09
| | | | | | | | | | | | | | | Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway.
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-28 21:56:34 +0000