2005-08-09 07:14:26 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* fe-connect.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* functions related to setting up a connection to the backend
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/interfaces/libpq/fe-connect.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#include "postgres_fe.h"
|
2000-09-27 17:17:57 +02:00
|
|
|
|
2002-08-30 01:06:32 +02:00
|
|
|
#include <sys/stat.h>
|
1999-07-19 04:27:16 +02:00
|
|
|
#include <fcntl.h>
|
|
|
|
#include <ctype.h>
|
2002-08-18 02:06:01 +02:00
|
|
|
#include <time.h>
|
2004-10-21 22:23:19 +02:00
|
|
|
#include <unistd.h>
|
1999-07-19 04:27:16 +02:00
|
|
|
|
1998-08-17 05:50:43 +02:00
|
|
|
#include "libpq-fe.h"
|
|
|
|
#include "libpq-int.h"
|
|
|
|
#include "fe-auth.h"
|
2004-05-21 22:56:50 +02:00
|
|
|
#include "pg_config_paths.h"
|
1998-08-17 05:50:43 +02:00
|
|
|
|
1998-07-03 06:29:04 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "win32.h"
|
2005-01-10 01:19:51 +01:00
|
|
|
#ifdef _WIN32_IE
|
|
|
|
#undef _WIN32_IE
|
|
|
|
#endif
|
2005-01-26 20:24:03 +01:00
|
|
|
#define _WIN32_IE 0x0500
|
2005-01-10 01:19:51 +01:00
|
|
|
#ifdef near
|
|
|
|
#undef near
|
|
|
|
#endif
|
|
|
|
#define near
|
2005-01-06 19:29:11 +01:00
|
|
|
#include <shlobj.h>
|
2017-05-17 22:31:56 +02:00
|
|
|
#ifdef _MSC_VER /* mstcpip.h is missing on mingw */
|
2010-07-08 12:20:14 +02:00
|
|
|
#include <mstcpip.h>
|
2010-07-08 18:19:50 +02:00
|
|
|
#endif
|
1998-07-03 06:29:04 +02:00
|
|
|
#else
|
2000-01-18 20:05:31 +01:00
|
|
|
#include <sys/socket.h>
|
1996-07-09 08:22:35 +02:00
|
|
|
#include <netdb.h>
|
2000-05-21 23:19:53 +02:00
|
|
|
#include <netinet/in.h>
|
2000-09-27 17:17:57 +02:00
|
|
|
#ifdef HAVE_NETINET_TCP_H
|
2001-03-22 05:01:46 +01:00
|
|
|
#include <netinet/tcp.h>
|
2000-09-27 17:17:57 +02:00
|
|
|
#endif
|
1998-07-03 06:29:04 +02:00
|
|
|
#endif
|
1996-11-03 08:14:32 +01:00
|
|
|
|
2004-01-09 03:02:43 +01:00
|
|
|
#ifdef ENABLE_THREAD_SAFETY
|
2005-08-23 23:02:05 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "pthread-win32.h"
|
|
|
|
#else
|
2004-01-09 03:02:43 +01:00
|
|
|
#include <pthread.h>
|
|
|
|
#endif
|
2005-08-23 23:02:05 +02:00
|
|
|
#endif
|
2004-01-09 03:02:43 +01:00
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
#ifdef USE_LDAP
|
|
|
|
#ifdef WIN32
|
|
|
|
#include <winldap.h>
|
|
|
|
#else
|
|
|
|
/* OpenLDAP deprecates RFC 1823, but we want standard conformance */
|
|
|
|
#define LDAP_DEPRECATED 1
|
|
|
|
#include <ldap.h>
|
|
|
|
typedef struct timeval LDAP_TIMEVAL;
|
|
|
|
#endif
|
|
|
|
static int ldapServiceLookup(const char *purl, PQconninfoOption *options,
|
2006-10-04 02:30:14 +02:00
|
|
|
PQExpBuffer errorMessage);
|
2006-07-27 15:20:24 +02:00
|
|
|
#endif
|
|
|
|
|
2016-09-02 12:49:59 +02:00
|
|
|
#include "common/ip.h"
|
2017-12-19 00:05:24 +01:00
|
|
|
#include "common/scram-common.h"
|
1998-07-24 05:32:46 +02:00
|
|
|
#include "mb/pg_wchar.h"
|
2017-10-02 00:36:14 +02:00
|
|
|
#include "port/pg_bswap.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2004-10-21 22:23:19 +02:00
|
|
|
|
2005-01-06 19:29:11 +01:00
|
|
|
#ifndef WIN32
|
2003-06-08 19:43:00 +02:00
|
|
|
#define PGPASSFILE ".pgpass"
|
2005-01-06 19:29:11 +01:00
|
|
|
#else
|
2005-01-14 01:25:56 +01:00
|
|
|
#define PGPASSFILE "pgpass.conf"
|
2005-01-06 19:29:11 +01:00
|
|
|
#endif
|
2000-01-18 20:05:31 +01:00
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
/*
|
2010-02-17 05:19:41 +01:00
|
|
|
* Pre-9.0 servers will return this SQLSTATE if asked to set
|
2009-12-02 05:38:35 +01:00
|
|
|
* application_name in a startup packet. We hard-wire the value rather
|
|
|
|
* than looking into errcodes.h since it reflects historical behavior
|
|
|
|
* rather than that of the current code.
|
|
|
|
*/
|
|
|
|
#define ERRCODE_APPNAME_UNKNOWN "42704"
|
|
|
|
|
2010-03-13 15:55:57 +01:00
|
|
|
/* This is part of the protocol so just define it */
|
|
|
|
#define ERRCODE_INVALID_PASSWORD "28P01"
|
2010-11-27 07:30:34 +01:00
|
|
|
/* This too */
|
|
|
|
#define ERRCODE_CANNOT_CONNECT_NOW "57P03"
|
2010-03-13 15:55:57 +01:00
|
|
|
|
2017-06-28 18:30:16 +02:00
|
|
|
/*
|
|
|
|
* Cope with the various platform-specific ways to spell TCP keepalive socket
|
|
|
|
* options. This doesn't cover Windows, which as usual does its own thing.
|
|
|
|
*/
|
|
|
|
#if defined(TCP_KEEPIDLE)
|
|
|
|
/* TCP_KEEPIDLE is the name of this option on Linux and *BSD */
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPIDLE
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPIDLE"
|
|
|
|
#elif defined(TCP_KEEPALIVE_THRESHOLD)
|
|
|
|
/* TCP_KEEPALIVE_THRESHOLD is the name of this option on Solaris >= 11 */
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPALIVE_THRESHOLD
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPALIVE_THRESHOLD"
|
|
|
|
#elif defined(TCP_KEEPALIVE) && defined(__darwin__)
|
|
|
|
/* TCP_KEEPALIVE is the name of this option on macOS */
|
|
|
|
/* Caution: Solaris has this symbol but it means something different */
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE TCP_KEEPALIVE
|
|
|
|
#define PG_TCP_KEEPALIVE_IDLE_STR "TCP_KEEPALIVE"
|
|
|
|
#endif
|
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
/*
|
|
|
|
* fall back options if they are not specified by arguments or defined
|
|
|
|
* by environment variables
|
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
#define DefaultHost "localhost"
|
|
|
|
#define DefaultTty ""
|
|
|
|
#define DefaultOption ""
|
|
|
|
#define DefaultAuthtype ""
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
#define DefaultTargetSessionAttrs "any"
|
2017-12-19 00:05:24 +01:00
|
|
|
#define DefaultSCRAMChannelBinding SCRAM_CHANNEL_BINDING_TLS_UNIQUE
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
#ifdef USE_SSL
|
2009-04-24 11:43:10 +02:00
|
|
|
#define DefaultSSLMode "prefer"
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
#else
|
|
|
|
#define DefaultSSLMode "disable"
|
|
|
|
#endif
|
2002-06-14 06:09:37 +02:00
|
|
|
|
1996-11-09 11:39:54 +01:00
|
|
|
/* ----------
|
1996-11-14 11:25:54 +01:00
|
|
|
* Definition of the conninfo parameters and their fallback resources.
|
2000-03-11 04:08:37 +01:00
|
|
|
*
|
1996-11-09 11:39:54 +01:00
|
|
|
* If Environment-Var and Compiled-in are specified as NULL, no
|
|
|
|
* fallback is available. If after all no value can be determined
|
|
|
|
* for an option, an error is returned.
|
|
|
|
*
|
2012-03-22 17:08:34 +01:00
|
|
|
* The value for the username is treated specially in conninfo_add_defaults.
|
|
|
|
* If the value is not obtained any other way, the username is determined
|
|
|
|
* by pg_fe_getauthname().
|
1996-11-09 11:39:54 +01:00
|
|
|
*
|
|
|
|
* The Label and Disp-Char entries are provided for applications that
|
|
|
|
* want to use PQconndefaults() to create a generic database connection
|
|
|
|
* dialog. Disp-Char is defined as follows:
|
2000-03-11 04:08:37 +01:00
|
|
|
* "" Normal input field
|
|
|
|
* "*" Password field - hide value
|
|
|
|
* "D" Debug option - don't show by default
|
|
|
|
*
|
|
|
|
* PQconninfoOptions[] is a constant static array that we use to initialize
|
|
|
|
* a dynamically allocated working copy. All the "val" fields in
|
2014-05-06 18:12:18 +02:00
|
|
|
* PQconninfoOptions[] *must* be NULL. In a working copy, non-null "val"
|
2000-03-11 04:08:37 +01:00
|
|
|
* fields point to malloc'd strings that should be freed when the working
|
|
|
|
* array is freed (see PQconninfoFree).
|
2012-11-30 07:09:18 +01:00
|
|
|
*
|
|
|
|
* The first part of each struct is identical to the one in libpq-fe.h,
|
|
|
|
* which is required since we memcpy() data between the two!
|
1996-11-09 11:39:54 +01:00
|
|
|
* ----------
|
|
|
|
*/
|
2012-11-30 07:09:18 +01:00
|
|
|
typedef struct _internalPQconninfoOption
|
|
|
|
{
|
|
|
|
char *keyword; /* The keyword of the option */
|
|
|
|
char *envvar; /* Fallback environment variable name */
|
|
|
|
char *compiled; /* Fallback compiled in default value */
|
|
|
|
char *val; /* Option's current value, or NULL */
|
|
|
|
char *label; /* Label for field in connect dialog */
|
|
|
|
char *dispchar; /* Indicates how to display this field in a
|
|
|
|
* connect dialog. Values are: "" Display
|
|
|
|
* entered value as is "*" Password field -
|
|
|
|
* hide value "D" Debug option - don't show
|
|
|
|
* by default */
|
|
|
|
int dispsize; /* Field size in characters for dialog */
|
|
|
|
/* ---
|
|
|
|
* Anything above this comment must be synchronized with
|
|
|
|
* PQconninfoOption in libpq-fe.h, since we memcpy() data
|
|
|
|
* between them!
|
|
|
|
* ---
|
|
|
|
*/
|
|
|
|
off_t connofs; /* Offset into PGconn struct, -1 if not there */
|
2013-05-29 22:58:43 +02:00
|
|
|
} internalPQconninfoOption;
|
2012-11-30 07:09:18 +01:00
|
|
|
|
|
|
|
static const internalPQconninfoOption PQconninfoOptions[] = {
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* "authtype" is no longer used, so mark it "don't show". We keep it in
|
|
|
|
* the array so as not to reject conninfo strings from old apps that might
|
|
|
|
* still try to set it.
|
2000-03-11 04:08:37 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
{"authtype", "PGAUTHTYPE", DefaultAuthtype, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Authtype", "D", 20, -1},
|
1997-03-12 22:23:16 +01:00
|
|
|
|
2000-10-17 03:00:58 +02:00
|
|
|
{"service", "PGSERVICE", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Service", "", 20, -1},
|
2000-10-17 03:00:58 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
{"user", "PGUSER", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-User", "", 20,
|
|
|
|
offsetof(struct pg_conn, pguser)},
|
1996-11-09 11:39:54 +01:00
|
|
|
|
2003-04-28 06:52:13 +02:00
|
|
|
{"password", "PGPASSWORD", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Password", "*", 20,
|
|
|
|
offsetof(struct pg_conn, pgpass)},
|
1997-03-12 22:23:16 +01:00
|
|
|
|
2017-01-24 23:06:21 +01:00
|
|
|
{"passfile", "PGPASSFILE", NULL, NULL,
|
|
|
|
"Database-Password-File", "", 64,
|
|
|
|
offsetof(struct pg_conn, pgpassfile)},
|
|
|
|
|
2002-08-18 03:35:40 +02:00
|
|
|
{"connect_timeout", "PGCONNECT_TIMEOUT", NULL, NULL,
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
"Connect-timeout", "", 10, /* strlen(INT32_MAX) == 10 */
|
2012-11-30 07:09:18 +01:00
|
|
|
offsetof(struct pg_conn, connect_timeout)},
|
2002-08-17 14:33:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
{"dbname", "PGDATABASE", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Name", "", 20,
|
|
|
|
offsetof(struct pg_conn, dbName)},
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1997-11-07 21:52:15 +01:00
|
|
|
{"host", "PGHOST", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Host", "", 40,
|
|
|
|
offsetof(struct pg_conn, pghost)},
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
{"hostaddr", "PGHOSTADDR", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Host-IP-Address", "", 45,
|
|
|
|
offsetof(struct pg_conn, pghostaddr)},
|
2003-01-08 17:21:53 +01:00
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
{"port", "PGPORT", DEF_PGPORT_STR, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Database-Port", "", 6,
|
|
|
|
offsetof(struct pg_conn, pgport)},
|
1996-11-09 11:39:54 +01:00
|
|
|
|
2011-02-19 07:54:58 +01:00
|
|
|
{"client_encoding", "PGCLIENTENCODING", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Client-Encoding", "", 10,
|
|
|
|
offsetof(struct pg_conn, client_encoding_initial)},
|
2011-02-19 07:54:58 +01:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/*
|
|
|
|
* "tty" is no longer used either, but keep it present for backwards
|
|
|
|
* compatibility.
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
{"tty", "PGTTY", DefaultTty, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Backend-Debug-TTY", "D", 40,
|
|
|
|
offsetof(struct pg_conn, pgtty)},
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
{"options", "PGOPTIONS", DefaultOption, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Backend-Debug-Options", "D", 40,
|
|
|
|
offsetof(struct pg_conn, pgoptions)},
|
2000-03-11 04:08:37 +01:00
|
|
|
|
2009-11-29 00:38:08 +01:00
|
|
|
{"application_name", "PGAPPNAME", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Application-Name", "", 64,
|
|
|
|
offsetof(struct pg_conn, appname)},
|
2009-11-29 00:38:08 +01:00
|
|
|
|
|
|
|
{"fallback_application_name", NULL, NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Fallback-Application-Name", "", 64,
|
|
|
|
offsetof(struct pg_conn, fbappname)},
|
2009-11-29 00:38:08 +01:00
|
|
|
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
{"keepalives", NULL, NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"TCP-Keepalives", "", 1, /* should be just '0' or '1' */
|
|
|
|
offsetof(struct pg_conn, keepalives)},
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
{"keepalives_idle", NULL, NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"TCP-Keepalives-Idle", "", 10, /* strlen(INT32_MAX) == 10 */
|
|
|
|
offsetof(struct pg_conn, keepalives_idle)},
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
{"keepalives_interval", NULL, NULL, NULL,
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
"TCP-Keepalives-Interval", "", 10, /* strlen(INT32_MAX) == 10 */
|
2012-11-30 07:09:18 +01:00
|
|
|
offsetof(struct pg_conn, keepalives_interval)},
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
{"keepalives_count", NULL, NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"TCP-Keepalives-Count", "", 10, /* strlen(INT32_MAX) == 10 */
|
|
|
|
offsetof(struct pg_conn, keepalives_count)},
|
2000-08-30 16:54:24 +02:00
|
|
|
|
2017-12-19 00:05:24 +01:00
|
|
|
{"scram_channel_binding", NULL, DefaultSCRAMChannelBinding, NULL,
|
|
|
|
"SCRAM-Channel-Binding", "D",
|
|
|
|
21, /* sizeof("tls-server-end-point") == 21 */
|
|
|
|
offsetof(struct pg_conn, scram_channel_binding)},
|
|
|
|
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
/*
|
2008-12-15 11:28:22 +01:00
|
|
|
* ssl options are allowed even without client SSL support because the
|
2009-06-11 16:49:15 +02:00
|
|
|
* client can still handle SSL modes "disable" and "allow". Other
|
|
|
|
* parameters have no effect on non-SSL connections, so there is no reason
|
|
|
|
* to exclude them since none of them are mandatory.
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
*/
|
|
|
|
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
|
2014-03-17 02:43:40 +01:00
|
|
|
"SSL-Mode", "", 12, /* sizeof("verify-full") == 12 */
|
2012-11-30 07:09:18 +01:00
|
|
|
offsetof(struct pg_conn, sslmode)},
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
|
2018-03-17 13:56:50 +01:00
|
|
|
{"sslcompression", "PGSSLCOMPRESSION", "0", NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"SSL-Compression", "", 1,
|
|
|
|
offsetof(struct pg_conn, sslcompression)},
|
2011-11-28 13:13:42 +01:00
|
|
|
|
2008-12-15 11:28:22 +01:00
|
|
|
{"sslcert", "PGSSLCERT", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"SSL-Client-Cert", "", 64,
|
|
|
|
offsetof(struct pg_conn, sslcert)},
|
2008-12-15 11:28:22 +01:00
|
|
|
|
|
|
|
{"sslkey", "PGSSLKEY", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"SSL-Client-Key", "", 64,
|
|
|
|
offsetof(struct pg_conn, sslkey)},
|
2008-12-15 11:28:22 +01:00
|
|
|
|
|
|
|
{"sslrootcert", "PGSSLROOTCERT", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"SSL-Root-Certificate", "", 64,
|
|
|
|
offsetof(struct pg_conn, sslrootcert)},
|
2008-12-15 11:28:22 +01:00
|
|
|
|
|
|
|
{"sslcrl", "PGSSLCRL", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"SSL-Revocation-List", "", 64,
|
|
|
|
offsetof(struct pg_conn, sslcrl)},
|
2008-12-15 11:28:22 +01:00
|
|
|
|
2010-07-18 13:37:26 +02:00
|
|
|
{"requirepeer", "PGREQUIREPEER", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Require-Peer", "", 10,
|
|
|
|
offsetof(struct pg_conn, requirepeer)},
|
2010-07-18 13:37:26 +02:00
|
|
|
|
2014-01-15 17:24:01 +01:00
|
|
|
#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
|
2007-07-10 15:14:22 +02:00
|
|
|
/* Kerberos and GSSAPI authentication support specifying the service name */
|
2005-06-04 22:42:43 +02:00
|
|
|
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Kerberos-service-name", "", 20,
|
|
|
|
offsetof(struct pg_conn, krbsrvname)},
|
2005-06-04 22:42:43 +02:00
|
|
|
#endif
|
|
|
|
|
2007-07-23 12:16:54 +02:00
|
|
|
#if defined(ENABLE_GSS) && defined(ENABLE_SSPI)
|
2007-11-15 22:14:46 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GSSAPI and SSPI both enabled, give a way to override which is used by
|
|
|
|
* default
|
|
|
|
*/
|
2007-07-23 12:16:54 +02:00
|
|
|
{"gsslib", "PGGSSLIB", NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"GSS-library", "", 7, /* sizeof("gssapi") = 7 */
|
|
|
|
offsetof(struct pg_conn, gsslib)},
|
2007-07-23 12:16:54 +02:00
|
|
|
#endif
|
|
|
|
|
2010-01-15 10:19:10 +01:00
|
|
|
{"replication", NULL, NULL, NULL,
|
2012-11-30 07:09:18 +01:00
|
|
|
"Replication", "D", 5,
|
|
|
|
offsetof(struct pg_conn, replication)},
|
2010-01-15 10:19:10 +01:00
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
{"target_session_attrs", "PGTARGETSESSIONATTRS",
|
|
|
|
DefaultTargetSessionAttrs, NULL,
|
|
|
|
"Target-Session-Attrs", "", 11, /* sizeof("read-write") = 11 */
|
|
|
|
offsetof(struct pg_conn, target_session_attrs)},
|
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
/* Terminating entry --- MUST BE LAST */
|
1997-09-07 07:04:48 +02:00
|
|
|
{NULL, NULL, NULL, NULL,
|
|
|
|
NULL, NULL, 0}
|
1996-11-09 11:39:54 +01:00
|
|
|
};
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
static const PQEnvironmentOption EnvironmentOptions[] =
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-14 16:38:31 +01:00
|
|
|
/* common user-interface settings */
|
1998-02-26 05:46:47 +01:00
|
|
|
{
|
|
|
|
"PGDATESTYLE", "datestyle"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"PGTZ", "timezone"
|
|
|
|
},
|
1997-11-14 16:38:31 +01:00
|
|
|
/* internal performance-related settings */
|
1998-02-26 05:46:47 +01:00
|
|
|
{
|
|
|
|
"PGGEQO", "geqo"
|
|
|
|
},
|
|
|
|
{
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
NULL, NULL
|
1998-02-26 05:46:47 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
};
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/* The connection URI must start with either of the following designators: */
|
|
|
|
static const char uri_designator[] = "postgresql://";
|
|
|
|
static const char short_uri_designator[] = "postgres://";
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
static bool connectOptions1(PGconn *conn, const char *conninfo);
|
|
|
|
static bool connectOptions2(PGconn *conn);
|
2000-04-12 19:17:23 +02:00
|
|
|
static int connectDBStart(PGconn *conn);
|
|
|
|
static int connectDBComplete(PGconn *conn);
|
2010-11-25 19:09:38 +01:00
|
|
|
static PGPing internal_ping(PGconn *conn);
|
2000-03-11 04:08:37 +01:00
|
|
|
static PGconn *makeEmptyPGconn(void);
|
2014-11-25 11:55:00 +01:00
|
|
|
static bool fillPGconn(PGconn *conn, PQconninfoOption *connOptions);
|
2000-03-11 04:08:37 +01:00
|
|
|
static void freePGconn(PGconn *conn);
|
|
|
|
static void closePGconn(PGconn *conn);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
static void release_all_addrinfo(PGconn *conn);
|
|
|
|
static void sendTerminateConn(PGconn *conn);
|
2012-03-22 17:08:34 +01:00
|
|
|
static PQconninfoOption *conninfo_init(PQExpBuffer errorMessage);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
static PQconninfoOption *parse_connection_string(const char *conninfo,
|
|
|
|
PQExpBuffer errorMessage, bool use_defaults);
|
2015-04-02 16:10:22 +02:00
|
|
|
static int uri_prefix_length(const char *connstr);
|
|
|
|
static bool recognized_connection_string(const char *connstr);
|
2000-03-11 04:08:37 +01:00
|
|
|
static PQconninfoOption *conninfo_parse(const char *conninfo,
|
2008-09-22 16:21:44 +02:00
|
|
|
PQExpBuffer errorMessage, bool use_defaults);
|
2017-06-21 20:39:04 +02:00
|
|
|
static PQconninfoOption *conninfo_array_parse(const char *const *keywords,
|
|
|
|
const char *const *values, PQExpBuffer errorMessage,
|
2010-02-26 03:01:40 +01:00
|
|
|
bool use_defaults, int expand_dbname);
|
2012-03-22 17:08:34 +01:00
|
|
|
static bool conninfo_add_defaults(PQconninfoOption *options,
|
|
|
|
PQExpBuffer errorMessage);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
static PQconninfoOption *conninfo_uri_parse(const char *uri,
|
2012-06-10 21:20:04 +02:00
|
|
|
PQExpBuffer errorMessage, bool use_defaults);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
static bool conninfo_uri_parse_options(PQconninfoOption *options,
|
|
|
|
const char *uri, PQExpBuffer errorMessage);
|
|
|
|
static bool conninfo_uri_parse_params(char *params,
|
|
|
|
PQconninfoOption *connOptions,
|
|
|
|
PQExpBuffer errorMessage);
|
|
|
|
static char *conninfo_uri_decode(const char *str, PQExpBuffer errorMessage);
|
|
|
|
static bool get_hexdigit(char digit, int *value);
|
|
|
|
static const char *conninfo_getval(PQconninfoOption *connOptions,
|
2000-04-12 19:17:23 +02:00
|
|
|
const char *keyword);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
static PQconninfoOption *conninfo_storeval(PQconninfoOption *connOptions,
|
2012-06-10 21:20:04 +02:00
|
|
|
const char *keyword, const char *value,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
PQExpBuffer errorMessage, bool ignoreMissing, bool uri_decode);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
static PQconninfoOption *conninfo_find(PQconninfoOption *connOptions,
|
|
|
|
const char *keyword);
|
2003-06-21 23:51:35 +02:00
|
|
|
static void defaultNoticeReceiver(void *arg, const PGresult *res);
|
2000-03-11 04:08:37 +01:00
|
|
|
static void defaultNoticeProcessor(void *arg, const char *message);
|
2001-03-22 05:01:46 +01:00
|
|
|
static int parseServiceInfo(PQconninfoOption *options,
|
|
|
|
PQExpBuffer errorMessage);
|
2010-01-20 22:15:21 +01:00
|
|
|
static int parseServiceFile(const char *serviceFile,
|
2010-02-26 03:01:40 +01:00
|
|
|
const char *service,
|
|
|
|
PQconninfoOption *options,
|
|
|
|
PQExpBuffer errorMessage,
|
|
|
|
bool *group_found);
|
2017-10-31 15:34:31 +01:00
|
|
|
static char *pwdfMatchesString(char *buf, const char *token);
|
|
|
|
static char *passwordFromFile(const char *hostname, const char *port, const char *dbname,
|
|
|
|
const char *username, const char *pgpassfile);
|
2017-01-24 23:06:21 +01:00
|
|
|
static void pgpassfileWarning(PGconn *conn);
|
2004-12-03 00:20:21 +01:00
|
|
|
static void default_threadlock(int acquire);
|
|
|
|
|
|
|
|
|
|
|
|
/* global variable because fe-auth.c needs to access it */
|
|
|
|
pgthreadlock_t pg_g_threadlock = default_threadlock;
|
2000-03-11 04:08:37 +01:00
|
|
|
|
2004-01-09 03:02:43 +01:00
|
|
|
|
2012-09-07 22:02:23 +02:00
|
|
|
/*
|
|
|
|
* pqDropConnection
|
|
|
|
*
|
|
|
|
* Close any physical connection to the server, and reset associated
|
2014-05-06 18:12:18 +02:00
|
|
|
* state inside the connection object. We don't release state that
|
2012-09-07 22:02:23 +02:00
|
|
|
* would be needed to reconnect, though.
|
2015-11-12 19:03:52 +01:00
|
|
|
*
|
|
|
|
* We can always flush the output buffer, since there's no longer any hope
|
|
|
|
* of sending that data. However, unprocessed input data might still be
|
|
|
|
* valuable, so the caller must tell us whether to flush that or not.
|
2012-09-07 22:02:23 +02:00
|
|
|
*/
|
|
|
|
void
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(PGconn *conn, bool flushInput)
|
2012-09-07 22:02:23 +02:00
|
|
|
{
|
|
|
|
/* Drop any SSL state */
|
|
|
|
pqsecure_close(conn);
|
Clear auth context correctly when re-connecting after failed auth attempt.
If authentication over an SSL connection fails, with sslmode=prefer,
libpq will reconnect without SSL and retry. However, we did not clear
the variables related to GSS, SSPI, and SASL authentication state, when
reconnecting. Because of that, the second authentication attempt would
always fail with a "duplicate GSS/SASL authentication request" error.
pg_SSPI_startup did not check for duplicate authentication requests like
the corresponding GSS and SASL functions, so with SSPI, you would leak
some memory instead.
Another way this could manifest itself, on version 10, is if you list
multiple hostnames in the "host" parameter. If the first server requests
Kerberos or SCRAM authentication, but it fails, the attempts to connect to
the other servers will also fail with "duplicate authentication request"
errors.
To fix, move the clearing of authentication state from closePGconn to
pgDropConnection, so that it is cleared also when re-connecting.
Patch by Michael Paquier, with some kibitzing by me.
Backpatch down to 9.3. 9.2 has the same bug, but the code around closing
the connection is somewhat different, so that this patch doesn't apply.
To fix this in 9.2, I think we would need to back-port commit 210eb9b743
first, and then apply this patch. However, given that we only bumped into
this in our own testing, we haven't heard any reports from users about
this, and that 9.2 will be end-of-lifed in a couple of months anyway, it
doesn't seem worth the risk and trouble.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
|
|
|
|
2012-09-07 22:02:23 +02:00
|
|
|
/* Close the socket itself */
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock != PGINVALID_SOCKET)
|
2012-09-07 22:02:23 +02:00
|
|
|
closesocket(conn->sock);
|
2014-04-17 01:46:51 +02:00
|
|
|
conn->sock = PGINVALID_SOCKET;
|
Clear auth context correctly when re-connecting after failed auth attempt.
If authentication over an SSL connection fails, with sslmode=prefer,
libpq will reconnect without SSL and retry. However, we did not clear
the variables related to GSS, SSPI, and SASL authentication state, when
reconnecting. Because of that, the second authentication attempt would
always fail with a "duplicate GSS/SASL authentication request" error.
pg_SSPI_startup did not check for duplicate authentication requests like
the corresponding GSS and SASL functions, so with SSPI, you would leak
some memory instead.
Another way this could manifest itself, on version 10, is if you list
multiple hostnames in the "host" parameter. If the first server requests
Kerberos or SCRAM authentication, but it fails, the attempts to connect to
the other servers will also fail with "duplicate authentication request"
errors.
To fix, move the clearing of authentication state from closePGconn to
pgDropConnection, so that it is cleared also when re-connecting.
Patch by Michael Paquier, with some kibitzing by me.
Backpatch down to 9.3. 9.2 has the same bug, but the code around closing
the connection is somewhat different, so that this patch doesn't apply.
To fix this in 9.2, I think we would need to back-port commit 210eb9b743
first, and then apply this patch. However, given that we only bumped into
this in our own testing, we haven't heard any reports from users about
this, and that 9.2 will be end-of-lifed in a couple of months anyway, it
doesn't seem worth the risk and trouble.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
|
|
|
|
2015-11-12 19:03:52 +01:00
|
|
|
/* Optionally discard any unread data */
|
|
|
|
if (flushInput)
|
|
|
|
conn->inStart = conn->inCursor = conn->inEnd = 0;
|
Clear auth context correctly when re-connecting after failed auth attempt.
If authentication over an SSL connection fails, with sslmode=prefer,
libpq will reconnect without SSL and retry. However, we did not clear
the variables related to GSS, SSPI, and SASL authentication state, when
reconnecting. Because of that, the second authentication attempt would
always fail with a "duplicate GSS/SASL authentication request" error.
pg_SSPI_startup did not check for duplicate authentication requests like
the corresponding GSS and SASL functions, so with SSPI, you would leak
some memory instead.
Another way this could manifest itself, on version 10, is if you list
multiple hostnames in the "host" parameter. If the first server requests
Kerberos or SCRAM authentication, but it fails, the attempts to connect to
the other servers will also fail with "duplicate authentication request"
errors.
To fix, move the clearing of authentication state from closePGconn to
pgDropConnection, so that it is cleared also when re-connecting.
Patch by Michael Paquier, with some kibitzing by me.
Backpatch down to 9.3. 9.2 has the same bug, but the code around closing
the connection is somewhat different, so that this patch doesn't apply.
To fix this in 9.2, I think we would need to back-port commit 210eb9b743
first, and then apply this patch. However, given that we only bumped into
this in our own testing, we haven't heard any reports from users about
this, and that 9.2 will be end-of-lifed in a couple of months anyway, it
doesn't seem worth the risk and trouble.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
|
|
|
|
2015-11-12 19:03:52 +01:00
|
|
|
/* Always discard any unsent data */
|
2012-09-07 22:02:23 +02:00
|
|
|
conn->outCount = 0;
|
Clear auth context correctly when re-connecting after failed auth attempt.
If authentication over an SSL connection fails, with sslmode=prefer,
libpq will reconnect without SSL and retry. However, we did not clear
the variables related to GSS, SSPI, and SASL authentication state, when
reconnecting. Because of that, the second authentication attempt would
always fail with a "duplicate GSS/SASL authentication request" error.
pg_SSPI_startup did not check for duplicate authentication requests like
the corresponding GSS and SASL functions, so with SSPI, you would leak
some memory instead.
Another way this could manifest itself, on version 10, is if you list
multiple hostnames in the "host" parameter. If the first server requests
Kerberos or SCRAM authentication, but it fails, the attempts to connect to
the other servers will also fail with "duplicate authentication request"
errors.
To fix, move the clearing of authentication state from closePGconn to
pgDropConnection, so that it is cleared also when re-connecting.
Patch by Michael Paquier, with some kibitzing by me.
Backpatch down to 9.3. 9.2 has the same bug, but the code around closing
the connection is somewhat different, so that this patch doesn't apply.
To fix this in 9.2, I think we would need to back-port commit 210eb9b743
first, and then apply this patch. However, given that we only bumped into
this in our own testing, we haven't heard any reports from users about
this, and that 9.2 will be end-of-lifed in a couple of months anyway, it
doesn't seem worth the risk and trouble.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com
2017-06-07 13:01:46 +02:00
|
|
|
|
|
|
|
/* Free authentication state */
|
|
|
|
#ifdef ENABLE_GSS
|
|
|
|
{
|
|
|
|
OM_uint32 min_s;
|
|
|
|
|
|
|
|
if (conn->gctx)
|
|
|
|
gss_delete_sec_context(&min_s, &conn->gctx, GSS_C_NO_BUFFER);
|
|
|
|
if (conn->gtarg_nam)
|
|
|
|
gss_release_name(&min_s, &conn->gtarg_nam);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#ifdef ENABLE_SSPI
|
|
|
|
if (conn->sspitarget)
|
|
|
|
{
|
|
|
|
free(conn->sspitarget);
|
|
|
|
conn->sspitarget = NULL;
|
|
|
|
}
|
|
|
|
if (conn->sspicred)
|
|
|
|
{
|
|
|
|
FreeCredentialsHandle(conn->sspicred);
|
|
|
|
free(conn->sspicred);
|
|
|
|
conn->sspicred = NULL;
|
|
|
|
}
|
|
|
|
if (conn->sspictx)
|
|
|
|
{
|
|
|
|
DeleteSecurityContext(conn->sspictx);
|
|
|
|
free(conn->sspictx);
|
|
|
|
conn->sspictx = NULL;
|
|
|
|
}
|
|
|
|
conn->usesspi = 0;
|
|
|
|
#endif
|
|
|
|
if (conn->sasl_state)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* XXX: if support for more authentication mechanisms is added, this
|
|
|
|
* needs to call the right 'free' function.
|
|
|
|
*/
|
|
|
|
pg_fe_scram_free(conn->sasl_state);
|
|
|
|
conn->sasl_state = NULL;
|
|
|
|
}
|
2012-09-07 22:02:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
/*
|
2000-04-12 19:17:23 +02:00
|
|
|
* Connecting to a Database
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
2010-01-28 07:28:26 +01:00
|
|
|
* There are now six different ways a user of this API can connect to the
|
1999-11-30 04:08:19 +01:00
|
|
|
* database. Two are not recommended for use in new code, because of their
|
|
|
|
* lack of extensibility with respect to the passing of options to the
|
|
|
|
* backend. These are PQsetdb and PQsetdbLogin (the former now being a macro
|
|
|
|
* to the latter).
|
|
|
|
*
|
|
|
|
* If it is desired to connect in a synchronous (blocking) manner, use the
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* function PQconnectdb or PQconnectdbParams. The former accepts a string of
|
|
|
|
* option = value pairs (or a URI) which must be parsed; the latter takes two
|
|
|
|
* NULL terminated arrays instead.
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
2003-03-10 23:28:22 +01:00
|
|
|
* To connect in an asynchronous (non-blocking) manner, use the functions
|
2010-02-26 03:01:40 +01:00
|
|
|
* PQconnectStart or PQconnectStartParams (which differ in the same way as
|
2010-01-28 07:28:26 +01:00
|
|
|
* PQconnectdb and PQconnectdbParams) and PQconnectPoll.
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
|
|
|
* Internally, the static functions connectDBStart, connectDBComplete
|
|
|
|
* are part of the connection procedure.
|
|
|
|
*/
|
|
|
|
|
2010-01-28 07:28:26 +01:00
|
|
|
/*
|
|
|
|
* PQconnectdbParams
|
|
|
|
*
|
|
|
|
* establishes a connection to a postgres backend through the postmaster
|
|
|
|
* using connection information in two arrays.
|
|
|
|
*
|
|
|
|
* The keywords array is defined as
|
|
|
|
*
|
|
|
|
* const char *params[] = {"option1", "option2", NULL}
|
|
|
|
*
|
|
|
|
* The values array is defined as
|
|
|
|
*
|
|
|
|
* const char *values[] = {"value1", "value2", NULL}
|
|
|
|
*
|
|
|
|
* Returns a PGconn* which is needed for all subsequent libpq calls, or NULL
|
|
|
|
* if a memory allocation failed.
|
|
|
|
* If the status field of the connection returned is CONNECTION_BAD,
|
|
|
|
* then some fields may be null'ed out instead of having valid values.
|
|
|
|
*
|
|
|
|
* You should call PQfinish (if conn is not NULL) regardless of whether this
|
|
|
|
* call succeeded.
|
|
|
|
*/
|
|
|
|
PGconn *
|
2017-06-21 20:39:04 +02:00
|
|
|
PQconnectdbParams(const char *const *keywords,
|
|
|
|
const char *const *values,
|
2010-02-05 04:09:05 +01:00
|
|
|
int expand_dbname)
|
2010-01-28 07:28:26 +01:00
|
|
|
{
|
2010-02-05 04:09:05 +01:00
|
|
|
PGconn *conn = PQconnectStartParams(keywords, values, expand_dbname);
|
2010-01-28 07:28:26 +01:00
|
|
|
|
|
|
|
if (conn && conn->status != CONNECTION_BAD)
|
|
|
|
(void) connectDBComplete(conn);
|
|
|
|
|
|
|
|
return conn;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2010-11-27 07:30:34 +01:00
|
|
|
/*
|
|
|
|
* PQpingParams
|
|
|
|
*
|
|
|
|
* check server status, accepting parameters identical to PQconnectdbParams
|
|
|
|
*/
|
2010-11-25 19:09:38 +01:00
|
|
|
PGPing
|
2017-06-21 20:39:04 +02:00
|
|
|
PQpingParams(const char *const *keywords,
|
|
|
|
const char *const *values,
|
2010-11-27 07:30:34 +01:00
|
|
|
int expand_dbname)
|
2010-11-25 19:09:38 +01:00
|
|
|
{
|
|
|
|
PGconn *conn = PQconnectStartParams(keywords, values, expand_dbname);
|
|
|
|
PGPing ret;
|
|
|
|
|
|
|
|
ret = internal_ping(conn);
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* PQconnectdb
|
|
|
|
*
|
1997-11-10 16:41:58 +01:00
|
|
|
* establishes a connection to a postgres backend through the postmaster
|
1996-11-09 11:39:54 +01:00
|
|
|
* using connection information in a string.
|
|
|
|
*
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* The conninfo string is either a whitespace-separated list of
|
1996-11-09 11:39:54 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* option = value
|
1996-11-09 11:39:54 +01:00
|
|
|
*
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* definitions or a URI (refer to the documentation for details.) Value
|
|
|
|
* might be a single value containing no whitespaces or a single quoted
|
|
|
|
* string. If a single quote should appear anywhere in the value, it must be
|
|
|
|
* escaped with a backslash like \'
|
1996-11-09 11:39:54 +01:00
|
|
|
*
|
1999-11-30 04:08:19 +01:00
|
|
|
* Returns a PGconn* which is needed for all subsequent libpq calls, or NULL
|
|
|
|
* if a memory allocation failed.
|
|
|
|
* If the status field of the connection returned is CONNECTION_BAD,
|
|
|
|
* then some fields may be null'ed out instead of having valid values.
|
|
|
|
*
|
|
|
|
* You should call PQfinish (if conn is not NULL) regardless of whether this
|
|
|
|
* call succeeded.
|
2000-01-14 06:33:15 +01:00
|
|
|
*/
|
1997-11-10 16:41:58 +01:00
|
|
|
PGconn *
|
1996-11-09 11:39:54 +01:00
|
|
|
PQconnectdb(const char *conninfo)
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
PGconn *conn = PQconnectStart(conninfo);
|
2000-01-14 06:33:15 +01:00
|
|
|
|
|
|
|
if (conn && conn->status != CONNECTION_BAD)
|
|
|
|
(void) connectDBComplete(conn);
|
1999-11-30 04:08:19 +01:00
|
|
|
|
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
|
2010-11-27 07:30:34 +01:00
|
|
|
/*
|
|
|
|
* PQping
|
|
|
|
*
|
|
|
|
* check server status, accepting parameters identical to PQconnectdb
|
|
|
|
*/
|
2010-11-25 19:09:38 +01:00
|
|
|
PGPing
|
|
|
|
PQping(const char *conninfo)
|
|
|
|
{
|
|
|
|
PGconn *conn = PQconnectStart(conninfo);
|
|
|
|
PGPing ret;
|
|
|
|
|
|
|
|
ret = internal_ping(conn);
|
|
|
|
PQfinish(conn);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
2010-01-28 07:28:26 +01:00
|
|
|
* PQconnectStartParams
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
|
|
|
* Begins the establishment of a connection to a postgres backend through the
|
2010-01-28 07:28:26 +01:00
|
|
|
* postmaster using connection information in a struct.
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
2010-01-28 07:28:26 +01:00
|
|
|
* See comment for PQconnectdbParams for the definition of the string format.
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
|
|
|
* Returns a PGconn*. If NULL is returned, a malloc error has occurred, and
|
2014-05-06 18:12:18 +02:00
|
|
|
* you should not attempt to proceed with this connection. If the status
|
1999-11-30 04:08:19 +01:00
|
|
|
* field of the connection returned is CONNECTION_BAD, an error has
|
|
|
|
* occurred. In this case you should call PQfinish on the result, (perhaps
|
|
|
|
* inspecting the error message first). Other fields of the structure may not
|
|
|
|
* be valid if that occurs. If the status field is not CONNECTION_BAD, then
|
|
|
|
* this stage has succeeded - call PQconnectPoll, using select(2) to see when
|
|
|
|
* this is necessary.
|
|
|
|
*
|
|
|
|
* See PQconnectPoll for more info.
|
2000-01-14 06:33:15 +01:00
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
PGconn *
|
2017-06-21 20:39:04 +02:00
|
|
|
PQconnectStartParams(const char *const *keywords,
|
|
|
|
const char *const *values,
|
2010-02-05 04:09:05 +01:00
|
|
|
int expand_dbname)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
PGconn *conn;
|
|
|
|
PQconninfoOption *connOptions;
|
1998-02-26 05:46:47 +01:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* Allocate memory for the conn structure
|
|
|
|
*/
|
1998-05-07 01:51:16 +02:00
|
|
|
conn = makeEmptyPGconn();
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn == NULL)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
1996-11-09 11:39:54 +01:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
2010-01-28 07:28:26 +01:00
|
|
|
* Parse the conninfo arrays
|
2003-04-28 06:29:12 +02:00
|
|
|
*/
|
2010-01-28 07:28:26 +01:00
|
|
|
connOptions = conninfo_array_parse(keywords, values,
|
2010-02-05 04:09:05 +01:00
|
|
|
&conn->errorMessage,
|
|
|
|
true, expand_dbname);
|
2010-01-28 07:28:26 +01:00
|
|
|
if (connOptions == NULL)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
/* errorMessage is already set */
|
2011-04-03 00:05:42 +02:00
|
|
|
return conn;
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Move option values into conn structure
|
|
|
|
*/
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!fillPGconn(conn, connOptions))
|
|
|
|
{
|
|
|
|
PQconninfoFree(connOptions);
|
|
|
|
return conn;
|
|
|
|
}
|
2010-01-28 07:28:26 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the option info - all is in conn now
|
|
|
|
*/
|
|
|
|
PQconninfoFree(connOptions);
|
2003-04-28 06:29:12 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute derived options
|
|
|
|
*/
|
|
|
|
if (!connectOptions2(conn))
|
|
|
|
return conn;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Connect to the database
|
|
|
|
*/
|
|
|
|
if (!connectDBStart(conn))
|
|
|
|
{
|
|
|
|
/* Just in case we failed to set it in connectDBStart */
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
}
|
|
|
|
|
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-01-28 07:28:26 +01:00
|
|
|
* PQconnectStart
|
2003-04-28 06:29:12 +02:00
|
|
|
*
|
2010-01-28 07:28:26 +01:00
|
|
|
* Begins the establishment of a connection to a postgres backend through the
|
|
|
|
* postmaster using connection information in a string.
|
2003-04-28 06:29:12 +02:00
|
|
|
*
|
2010-01-28 07:28:26 +01:00
|
|
|
* See comment for PQconnectdb for the definition of the string format.
|
|
|
|
*
|
|
|
|
* Returns a PGconn*. If NULL is returned, a malloc error has occurred, and
|
2014-05-06 18:12:18 +02:00
|
|
|
* you should not attempt to proceed with this connection. If the status
|
2010-01-28 07:28:26 +01:00
|
|
|
* field of the connection returned is CONNECTION_BAD, an error has
|
|
|
|
* occurred. In this case you should call PQfinish on the result, (perhaps
|
|
|
|
* inspecting the error message first). Other fields of the structure may not
|
|
|
|
* be valid if that occurs. If the status field is not CONNECTION_BAD, then
|
|
|
|
* this stage has succeeded - call PQconnectPoll, using select(2) to see when
|
|
|
|
* this is necessary.
|
|
|
|
*
|
|
|
|
* See PQconnectPoll for more info.
|
2003-04-28 06:29:12 +02:00
|
|
|
*/
|
2010-01-28 07:28:26 +01:00
|
|
|
PGconn *
|
|
|
|
PQconnectStart(const char *conninfo)
|
2003-04-28 06:29:12 +02:00
|
|
|
{
|
2010-01-28 07:28:26 +01:00
|
|
|
PGconn *conn;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate memory for the conn structure
|
|
|
|
*/
|
|
|
|
conn = makeEmptyPGconn();
|
|
|
|
if (conn == NULL)
|
|
|
|
return NULL;
|
2003-04-28 06:29:12 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2000-03-11 04:08:37 +01:00
|
|
|
* Parse the conninfo string
|
1996-11-09 11:39:54 +01:00
|
|
|
*/
|
2010-01-28 07:28:26 +01:00
|
|
|
if (!connectOptions1(conn, conninfo))
|
|
|
|
return conn;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute derived options
|
|
|
|
*/
|
|
|
|
if (!connectOptions2(conn))
|
|
|
|
return conn;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Connect to the database
|
|
|
|
*/
|
|
|
|
if (!connectDBStart(conn))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2010-01-28 07:28:26 +01:00
|
|
|
/* Just in case we failed to set it in connectDBStart */
|
1997-09-07 07:04:48 +02:00
|
|
|
conn->status = CONNECTION_BAD;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
2000-03-11 04:08:37 +01:00
|
|
|
|
2010-01-28 07:28:26 +01:00
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
|
2014-11-25 11:55:00 +01:00
|
|
|
/*
|
|
|
|
* Move option values into conn structure
|
|
|
|
*
|
|
|
|
* Don't put anything cute here --- intelligence should be in
|
|
|
|
* connectOptions2 ...
|
|
|
|
*
|
|
|
|
* Returns true on success. On failure, returns false and sets error message.
|
|
|
|
*/
|
|
|
|
static bool
|
2010-01-28 07:28:26 +01:00
|
|
|
fillPGconn(PGconn *conn, PQconninfoOption *connOptions)
|
|
|
|
{
|
2012-11-30 07:09:18 +01:00
|
|
|
const internalPQconninfoOption *option;
|
2010-01-28 07:28:26 +01:00
|
|
|
|
2012-11-30 07:09:18 +01:00
|
|
|
for (option = PQconninfoOptions; option->keyword; option++)
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
{
|
2014-11-30 18:20:44 +01:00
|
|
|
if (option->connofs >= 0)
|
2012-11-30 07:09:18 +01:00
|
|
|
{
|
2014-11-30 18:20:44 +01:00
|
|
|
const char *tmp = conninfo_getval(connOptions, option->keyword);
|
2012-11-30 07:09:18 +01:00
|
|
|
|
2014-11-25 11:55:00 +01:00
|
|
|
if (tmp)
|
|
|
|
{
|
2014-11-30 18:20:44 +01:00
|
|
|
char **connmember = (char **) ((char *) conn + option->connofs);
|
|
|
|
|
|
|
|
if (*connmember)
|
|
|
|
free(*connmember);
|
2014-11-25 11:55:00 +01:00
|
|
|
*connmember = strdup(tmp);
|
|
|
|
if (*connmember == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2012-11-30 07:09:18 +01:00
|
|
|
}
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
}
|
2014-11-25 11:55:00 +01:00
|
|
|
|
|
|
|
return true;
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* connectOptions1
|
|
|
|
*
|
|
|
|
* Internal subroutine to set up connection parameters given an already-
|
|
|
|
* created PGconn and a conninfo string. Derived settings should be
|
|
|
|
* processed by calling connectOptions2 next. (We split them because
|
|
|
|
* PQsetdbLogin overrides defaults in between.)
|
|
|
|
*
|
|
|
|
* Returns true if OK, false if trouble (in which case errorMessage is set
|
|
|
|
* and so is conn->status).
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
connectOptions1(PGconn *conn, const char *conninfo)
|
|
|
|
{
|
|
|
|
PQconninfoOption *connOptions;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Parse the conninfo string
|
|
|
|
*/
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
connOptions = parse_connection_string(conninfo, &conn->errorMessage, true);
|
2010-01-28 07:28:26 +01:00
|
|
|
if (connOptions == NULL)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
/* errorMessage is already set */
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Move option values into conn structure
|
|
|
|
*/
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!fillPGconn(conn, connOptions))
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
PQconninfoFree(connOptions);
|
|
|
|
return false;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2000-03-11 04:08:37 +01:00
|
|
|
* Free the option info - all is in conn now
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoFree(connOptions);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-07-10 11:28:57 +02:00
|
|
|
/*
|
|
|
|
* Count the number of elements in a simple comma-separated list.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
count_comma_separated_elems(const char *input)
|
|
|
|
{
|
|
|
|
int n;
|
|
|
|
|
|
|
|
n = 1;
|
|
|
|
for (; *input != '\0'; input++)
|
|
|
|
{
|
|
|
|
if (*input == ',')
|
|
|
|
n++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Parse a simple comma-separated list.
|
|
|
|
*
|
|
|
|
* On each call, returns a malloc'd copy of the next element, and sets *more
|
|
|
|
* to indicate whether there are any more elements in the list after this,
|
|
|
|
* and updates *startptr to point to the next element, if any.
|
|
|
|
*
|
|
|
|
* On out of memory, returns NULL.
|
|
|
|
*/
|
|
|
|
static char *
|
|
|
|
parse_comma_separated_list(char **startptr, bool *more)
|
|
|
|
{
|
|
|
|
char *p;
|
|
|
|
char *s = *startptr;
|
|
|
|
char *e;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search for the end of the current element; a comma or end-of-string
|
|
|
|
* acts as a terminator.
|
|
|
|
*/
|
|
|
|
e = s;
|
|
|
|
while (*e != '\0' && *e != ',')
|
|
|
|
++e;
|
|
|
|
*more = (*e == ',');
|
|
|
|
|
|
|
|
len = e - s;
|
|
|
|
p = (char *) malloc(sizeof(char) * (len + 1));
|
|
|
|
if (p)
|
|
|
|
{
|
|
|
|
memcpy(p, s, len);
|
|
|
|
p[len] = '\0';
|
|
|
|
}
|
|
|
|
*startptr = e + 1;
|
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
|
|
|
* connectOptions2
|
|
|
|
*
|
|
|
|
* Compute derived connection options after absorbing all user-supplied info.
|
|
|
|
*
|
|
|
|
* Returns true if OK, false if trouble (in which case errorMessage is set
|
|
|
|
* and so is conn->status).
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
connectOptions2(PGconn *conn)
|
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
/*
|
|
|
|
* Allocate memory for details about each host to which we might possibly
|
2017-07-10 11:28:57 +02:00
|
|
|
* try to connect. For that, count the number of elements in the hostaddr
|
|
|
|
* or host options. If neither is given, assume one host.
|
2016-11-03 14:25:20 +01:00
|
|
|
*/
|
|
|
|
conn->whichhost = 0;
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->pghostaddr && conn->pghostaddr[0] != '\0')
|
|
|
|
conn->nconnhost = count_comma_separated_elems(conn->pghostaddr);
|
|
|
|
else if (conn->pghost && conn->pghost[0] != '\0')
|
|
|
|
conn->nconnhost = count_comma_separated_elems(conn->pghost);
|
|
|
|
else
|
|
|
|
conn->nconnhost = 1;
|
2016-11-03 14:25:20 +01:00
|
|
|
conn->connhost = (pg_conn_host *)
|
|
|
|
calloc(conn->nconnhost, sizeof(pg_conn_host));
|
|
|
|
if (conn->connhost == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
|
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* We now have one pg_conn_host structure per possible host. Fill in the
|
|
|
|
* host details for each one.
|
2016-11-03 14:25:20 +01:00
|
|
|
*/
|
|
|
|
if (conn->pghostaddr != NULL && conn->pghostaddr[0] != '\0')
|
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
int i;
|
|
|
|
char *s = conn->pghostaddr;
|
|
|
|
bool more = true;
|
|
|
|
|
|
|
|
for (i = 0; i < conn->nconnhost && more; i++)
|
|
|
|
{
|
|
|
|
conn->connhost[i].hostaddr = parse_comma_separated_list(&s, &more);
|
|
|
|
if (conn->connhost[i].hostaddr == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
|
|
|
|
conn->connhost[i].type = CHT_HOST_ADDRESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If hostaddr was given, the array was allocated according to the
|
|
|
|
* number of elements in the hostaddr list, so it really should be the
|
|
|
|
* right size.
|
|
|
|
*/
|
|
|
|
Assert(!more);
|
|
|
|
Assert(i == conn->nconnhost);
|
2016-11-03 14:25:20 +01:00
|
|
|
}
|
2017-07-10 11:28:57 +02:00
|
|
|
|
|
|
|
if (conn->pghost != NULL && conn->pghost[0] != '\0')
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
int i;
|
2017-05-17 22:31:56 +02:00
|
|
|
char *s = conn->pghost;
|
2017-07-10 11:28:57 +02:00
|
|
|
bool more = true;
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2017-07-10 11:28:57 +02:00
|
|
|
for (i = 0; i < conn->nconnhost && more; i++)
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
conn->connhost[i].host = parse_comma_separated_list(&s, &more);
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->connhost[i].host == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
|
|
|
|
/* Identify the type of host. */
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->pghostaddr == NULL || conn->pghostaddr[0] == '\0')
|
|
|
|
{
|
|
|
|
conn->connhost[i].type = CHT_HOST_NAME;
|
2016-11-03 14:25:20 +01:00
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
2017-07-10 11:28:57 +02:00
|
|
|
if (is_absolute_path(conn->connhost[i].host))
|
|
|
|
conn->connhost[i].type = CHT_UNIX_SOCKET;
|
2016-11-03 14:25:20 +01:00
|
|
|
#endif
|
2017-07-10 11:28:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (more || i != conn->nconnhost)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
2018-01-21 13:40:55 +01:00
|
|
|
libpq_gettext("could not match %d host names to %d hostaddr values\n"),
|
2017-07-10 14:29:36 +02:00
|
|
|
count_comma_separated_elems(conn->pghost), conn->nconnhost);
|
2017-07-10 11:28:57 +02:00
|
|
|
return false;
|
2016-11-03 14:25:20 +01:00
|
|
|
}
|
|
|
|
}
|
2017-07-10 11:28:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If neither host or hostaddr options was given, connect to default host.
|
|
|
|
*/
|
|
|
|
if ((conn->pghostaddr == NULL || conn->pghostaddr[0] == '\0') &&
|
|
|
|
(conn->pghost == NULL || conn->pghost[0] == '\0'))
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
Assert(conn->nconnhost == 1);
|
2016-11-03 14:25:20 +01:00
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
|
|
|
conn->connhost[0].host = strdup(DEFAULT_PGSOCKET_DIR);
|
|
|
|
conn->connhost[0].type = CHT_UNIX_SOCKET;
|
|
|
|
#else
|
|
|
|
conn->connhost[0].host = strdup(DefaultHost);
|
|
|
|
conn->connhost[0].type = CHT_HOST_NAME;
|
|
|
|
#endif
|
|
|
|
if (conn->connhost[0].host == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Next, work out the port number corresponding to each host name.
|
|
|
|
*/
|
|
|
|
if (conn->pgport != NULL && conn->pgport[0] != '\0')
|
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
int i;
|
2017-05-17 22:31:56 +02:00
|
|
|
char *s = conn->pgport;
|
2017-07-10 11:28:57 +02:00
|
|
|
bool more = true;
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2017-07-10 11:28:57 +02:00
|
|
|
for (i = 0; i < conn->nconnhost && more; i++)
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
conn->connhost[i].port = parse_comma_separated_list(&s, &more);
|
|
|
|
if (conn->connhost[i].port == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
}
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2017-07-10 11:28:57 +02:00
|
|
|
/*
|
|
|
|
* If exactly one port was given, use it for every host. Otherwise,
|
|
|
|
* there must be exactly as many ports as there were hosts.
|
|
|
|
*/
|
|
|
|
if (i == 1 && !more)
|
|
|
|
{
|
|
|
|
for (i = 1; i < conn->nconnhost; i++)
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
conn->connhost[i].port = strdup(conn->connhost[0].port);
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->connhost[i].port == NULL)
|
|
|
|
goto oom_error;
|
|
|
|
}
|
|
|
|
}
|
2017-07-10 11:28:57 +02:00
|
|
|
else if (more || i != conn->nconnhost)
|
2016-11-03 14:25:20 +01:00
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not match %d port numbers to %d hosts\n"),
|
2017-07-10 11:28:57 +02:00
|
|
|
count_comma_separated_elems(conn->pgport), conn->nconnhost);
|
2016-11-03 14:25:20 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
/*
|
|
|
|
* If user name was not given, fetch it. (Most likely, the fetch will
|
|
|
|
* fail, since the only way we get here is if pg_fe_getauthname() failed
|
|
|
|
* during conninfo_add_defaults(). But now we want an error message.)
|
|
|
|
*/
|
|
|
|
if (conn->pguser == NULL || conn->pguser[0] == '\0')
|
|
|
|
{
|
|
|
|
if (conn->pguser)
|
|
|
|
free(conn->pguser);
|
|
|
|
conn->pguser = pg_fe_getauthname(&conn->errorMessage);
|
|
|
|
if (!conn->pguser)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-05 02:44:56 +02:00
|
|
|
/*
|
|
|
|
* If database name was not given, default it to equal user name
|
|
|
|
*/
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
if (conn->dbName == NULL || conn->dbName[0] == '\0')
|
2003-05-05 02:44:56 +02:00
|
|
|
{
|
|
|
|
if (conn->dbName)
|
|
|
|
free(conn->dbName);
|
|
|
|
conn->dbName = strdup(conn->pguser);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->dbName)
|
|
|
|
goto oom_error;
|
2003-05-05 02:44:56 +02:00
|
|
|
}
|
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Supply default password if none given. Note that the password might be
|
|
|
|
* different for each host/port pair.
|
2003-04-28 06:29:12 +02:00
|
|
|
*/
|
|
|
|
if (conn->pgpass == NULL || conn->pgpass[0] == '\0')
|
|
|
|
{
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
/* If password file wasn't specified, use ~/PGPASSFILE */
|
2017-01-24 23:06:21 +01:00
|
|
|
if (conn->pgpassfile == NULL || conn->pgpassfile[0] == '\0')
|
|
|
|
{
|
|
|
|
char homedir[MAXPGPATH];
|
|
|
|
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
if (pqGetHomeDirectory(homedir, sizeof(homedir)))
|
2017-01-24 23:06:21 +01:00
|
|
|
{
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
if (conn->pgpassfile)
|
|
|
|
free(conn->pgpassfile);
|
|
|
|
conn->pgpassfile = malloc(MAXPGPATH);
|
|
|
|
if (!conn->pgpassfile)
|
|
|
|
goto oom_error;
|
|
|
|
snprintf(conn->pgpassfile, MAXPGPATH, "%s/%s",
|
|
|
|
homedir, PGPASSFILE);
|
2017-01-24 23:06:21 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
if (conn->pgpassfile != NULL && conn->pgpassfile[0] != '\0')
|
2014-11-25 11:55:00 +01:00
|
|
|
{
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < conn->nconnhost; i++)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Try to get a password for this host from pgpassfile. We use
|
|
|
|
* host name rather than host address in the same manner as
|
|
|
|
* PQhost().
|
|
|
|
*/
|
|
|
|
char *pwhost = conn->connhost[i].host;
|
|
|
|
|
|
|
|
if (conn->connhost[i].type == CHT_HOST_ADDRESS &&
|
|
|
|
conn->connhost[i].host != NULL &&
|
|
|
|
conn->connhost[i].host[0] != '\0')
|
|
|
|
pwhost = conn->connhost[i].hostaddr;
|
|
|
|
|
|
|
|
conn->connhost[i].password =
|
|
|
|
passwordFromFile(pwhost,
|
|
|
|
conn->connhost[i].port,
|
|
|
|
conn->dbName,
|
|
|
|
conn->pguser,
|
|
|
|
conn->pgpassfile);
|
|
|
|
/* If we got one, set pgpassfile_used */
|
|
|
|
if (conn->connhost[i].password != NULL)
|
|
|
|
conn->pgpassfile_used = true;
|
|
|
|
}
|
2014-11-25 11:55:00 +01:00
|
|
|
}
|
2000-11-14 00:37:54 +01:00
|
|
|
}
|
|
|
|
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
/*
|
|
|
|
* validate sslmode option
|
|
|
|
*/
|
|
|
|
if (conn->sslmode)
|
|
|
|
{
|
|
|
|
if (strcmp(conn->sslmode, "disable") != 0
|
|
|
|
&& strcmp(conn->sslmode, "allow") != 0
|
|
|
|
&& strcmp(conn->sslmode, "prefer") != 0
|
2009-04-24 11:43:10 +02:00
|
|
|
&& strcmp(conn->sslmode, "require") != 0
|
|
|
|
&& strcmp(conn->sslmode, "verify-ca") != 0
|
|
|
|
&& strcmp(conn->sslmode, "verify-full") != 0)
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid sslmode value: \"%s\"\n"),
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->sslmode);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef USE_SSL
|
2003-08-04 02:43:34 +02:00
|
|
|
switch (conn->sslmode[0])
|
|
|
|
{
|
|
|
|
case 'a': /* "allow" */
|
|
|
|
case 'p': /* "prefer" */
|
|
|
|
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* warn user that an SSL connection will never be negotiated
|
|
|
|
* since SSL was not compiled in?
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
*/
|
|
|
|
break;
|
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
case 'r': /* "require" */
|
2009-04-24 11:43:10 +02:00
|
|
|
case 'v': /* "verify-ca" or "verify-full" */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
2003-09-22 02:23:35 +02:00
|
|
|
libpq_gettext("sslmode value \"%s\" invalid when SSL support is not compiled in\n"),
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->sslmode);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
else
|
2014-11-25 11:55:00 +01:00
|
|
|
{
|
2003-08-01 23:27:27 +02:00
|
|
|
conn->sslmode = strdup(DefaultSSLMode);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->sslmode)
|
|
|
|
goto oom_error;
|
|
|
|
}
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
|
2011-02-19 07:54:58 +01:00
|
|
|
/*
|
|
|
|
* Resolve special "auto" client_encoding from the locale
|
|
|
|
*/
|
|
|
|
if (conn->client_encoding_initial &&
|
|
|
|
strcmp(conn->client_encoding_initial, "auto") == 0)
|
|
|
|
{
|
|
|
|
free(conn->client_encoding_initial);
|
|
|
|
conn->client_encoding_initial = strdup(pg_encoding_to_char(pg_get_encoding_from_locale(NULL, true)));
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->client_encoding_initial)
|
|
|
|
goto oom_error;
|
2011-02-19 07:54:58 +01:00
|
|
|
}
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
/*
|
|
|
|
* Validate target_session_attrs option.
|
|
|
|
*/
|
|
|
|
if (conn->target_session_attrs)
|
|
|
|
{
|
|
|
|
if (strcmp(conn->target_session_attrs, "any") != 0
|
|
|
|
&& strcmp(conn->target_session_attrs, "read-write") != 0)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid target_session_attrs value: \"%s\"\n"),
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->target_session_attrs);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-02-13 23:33:57 +01:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Only if we get this far is it appropriate to try to connect. (We need a
|
|
|
|
* state flag, rather than just the boolean result of this function, in
|
|
|
|
* case someone tries to PQreset() the PGconn.)
|
2006-02-13 23:33:57 +01:00
|
|
|
*/
|
|
|
|
conn->options_valid = true;
|
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
return true;
|
2014-11-25 11:55:00 +01:00
|
|
|
|
|
|
|
oom_error:
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return false;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* PQconndefaults
|
|
|
|
*
|
2012-03-22 17:08:34 +01:00
|
|
|
* Construct a default connection options array, which identifies all the
|
|
|
|
* available options and shows any default values that are available from the
|
|
|
|
* environment etc. On error (eg out of memory), NULL is returned.
|
2000-03-11 04:08:37 +01:00
|
|
|
*
|
|
|
|
* Using this function, an application may determine all possible options
|
|
|
|
* and their current default values.
|
|
|
|
*
|
|
|
|
* NOTE: as of PostgreSQL 7.0, the returned array is dynamically allocated
|
2014-05-06 18:12:18 +02:00
|
|
|
* and should be freed when no longer needed via PQconninfoFree(). (In prior
|
2000-03-11 04:08:37 +01:00
|
|
|
* versions, the returned array was static, but that's not thread-safe.)
|
|
|
|
* Pre-7.0 applications that use this function will see a small memory leak
|
|
|
|
* until they are updated to call PQconninfoFree.
|
1996-11-09 11:39:54 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
PQconninfoOption *
|
1996-11-10 04:06:38 +01:00
|
|
|
PQconndefaults(void)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
PQExpBufferData errorBuf;
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoOption *connOptions;
|
1996-11-09 11:39:54 +01:00
|
|
|
|
2012-03-22 17:08:34 +01:00
|
|
|
/* We don't actually report any errors here, but callees want a buffer */
|
1999-08-31 03:37:37 +02:00
|
|
|
initPQExpBuffer(&errorBuf);
|
2011-10-19 03:44:23 +02:00
|
|
|
if (PQExpBufferDataBroken(errorBuf))
|
2008-09-22 15:55:14 +02:00
|
|
|
return NULL; /* out of memory already :-( */
|
2012-03-22 17:08:34 +01:00
|
|
|
|
|
|
|
connOptions = conninfo_init(&errorBuf);
|
|
|
|
if (connOptions != NULL)
|
|
|
|
{
|
2013-12-03 17:11:56 +01:00
|
|
|
/* pass NULL errorBuf to ignore errors */
|
|
|
|
if (!conninfo_add_defaults(connOptions, NULL))
|
2012-03-22 17:08:34 +01:00
|
|
|
{
|
|
|
|
PQconninfoFree(connOptions);
|
|
|
|
connOptions = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
termPQExpBuffer(&errorBuf);
|
2000-03-11 04:08:37 +01:00
|
|
|
return connOptions;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------
|
1997-12-04 01:28:15 +01:00
|
|
|
* PQsetdbLogin
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
1996-10-10 10:20:11 +02:00
|
|
|
* establishes a connection to a postgres backend through the postmaster
|
1996-07-09 08:22:35 +02:00
|
|
|
* at the specified host and port.
|
|
|
|
*
|
|
|
|
* returns a PGconn* which is needed for all subsequent libpq calls
|
1997-03-12 22:23:16 +01:00
|
|
|
*
|
2003-04-28 06:29:12 +02:00
|
|
|
* if the status field of the connection returned is CONNECTION_BAD,
|
|
|
|
* then only the errorMessage is likely to be useful.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
1998-02-26 05:46:47 +01:00
|
|
|
PGconn *
|
2000-01-14 06:33:15 +01:00
|
|
|
PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions,
|
|
|
|
const char *pgtty, const char *dbName, const char *login,
|
|
|
|
const char *pwd)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1999-02-05 05:25:55 +01:00
|
|
|
PGconn *conn;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
|
|
|
* Allocate memory for the conn structure
|
|
|
|
*/
|
1998-05-07 01:51:16 +02:00
|
|
|
conn = makeEmptyPGconn();
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn == NULL)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* If the dbName parameter contains what looks like a connection string,
|
|
|
|
* parse it into conn struct using connectOptions1.
|
2007-11-15 22:14:46 +01:00
|
|
|
*/
|
2015-04-02 16:10:22 +02:00
|
|
|
if (dbName && recognized_connection_string(dbName))
|
2007-11-15 22:14:46 +01:00
|
|
|
{
|
|
|
|
if (!connectOptions1(conn, dbName))
|
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Old-style path: first, parse an empty conninfo string in order to
|
|
|
|
* set up the same defaults that PQconnectdb() would use.
|
|
|
|
*/
|
|
|
|
if (!connectOptions1(conn, ""))
|
|
|
|
return conn;
|
|
|
|
|
|
|
|
/* Insert dbName parameter value into struct */
|
|
|
|
if (dbName && dbName[0] != '\0')
|
|
|
|
{
|
|
|
|
if (conn->dbName)
|
|
|
|
free(conn->dbName);
|
|
|
|
conn->dbName = strdup(dbName);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->dbName)
|
|
|
|
goto oom_error;
|
2007-11-15 22:14:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert remaining parameters into struct, overriding defaults (as well
|
|
|
|
* as any conflicting data from dbName taken as a conninfo).
|
2000-11-14 00:37:54 +01:00
|
|
|
*/
|
2003-04-28 06:29:12 +02:00
|
|
|
if (pghost && pghost[0] != '\0')
|
2000-11-14 00:37:54 +01:00
|
|
|
{
|
2003-04-28 06:29:12 +02:00
|
|
|
if (conn->pghost)
|
|
|
|
free(conn->pghost);
|
|
|
|
conn->pghost = strdup(pghost);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pghost)
|
|
|
|
goto oom_error;
|
2000-11-14 00:37:54 +01:00
|
|
|
}
|
UUNET is looking into offering PostgreSQL as a part of a managed web
hosting product, on both shared and dedicated machines. We currently
offer Oracle and MySQL, and it would be a nice middle-ground.
However, as shipped, PostgreSQL lacks the following features we need
that MySQL has:
1. The ability to listen only on a particular IP address. Each
hosting customer has their own IP address, on which all of their
servers (http, ftp, real media, etc.) run.
2. The ability to place the Unix-domain socket in a mode 700 directory.
This allows us to automatically create an empty database, with an
empty DBA password, for new or upgrading customers without having
to interactively set a DBA password and communicate it to (or from)
the customer. This in turn cuts down our install and upgrade times.
3. The ability to connect to the Unix-domain socket from within a
change-rooted environment. We run CGI programs chrooted to the
user's home directory, which is another reason why we need to be
able to specify where the Unix-domain socket is, instead of /tmp.
4. The ability to, if run as root, open a pid file in /var/run as
root, and then setuid to the desired user. (mysqld -u can almost
do this; I had to patch it, too).
The patch below fixes problem 1-3. I plan to address #4, also, but
haven't done so yet. These diffs are big enough that they should give
the PG development team something to think about in the meantime :-)
Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get
out what I have, which works (for the problems it tackles), now.
With these changes, we can set up and run PostgreSQL with scripts the
same way we can with apache or proftpd or mysql.
In summary, this patch makes the following enhancements:
1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT,
and command line options -k --unix-socket to the relevant programs.
2. Adds a -h option to postmaster to set the hostname or IP address to
listen on instead of the default INADDR_ANY.
3. Extends some library interfaces to support the above.
4. Fixes a few memory leaks in PQconnectdb().
The default behavior is unchanged from stock 7.0.2; if you don't use
any of these new features, they don't change the operation.
David J. MacKenzie
2000-11-13 16:18:15 +01:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
if (pgport && pgport[0] != '\0')
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-04-28 06:29:12 +02:00
|
|
|
if (conn->pgport)
|
|
|
|
free(conn->pgport);
|
|
|
|
conn->pgport = strdup(pgport);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pgport)
|
|
|
|
goto oom_error;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
if (pgoptions && pgoptions[0] != '\0')
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-04-28 06:29:12 +02:00
|
|
|
if (conn->pgoptions)
|
|
|
|
free(conn->pgoptions);
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->pgoptions = strdup(pgoptions);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pgoptions)
|
|
|
|
goto oom_error;
|
2003-04-28 06:29:12 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
if (pgtty && pgtty[0] != '\0')
|
1999-08-31 03:37:37 +02:00
|
|
|
{
|
2003-04-28 06:29:12 +02:00
|
|
|
if (conn->pgtty)
|
|
|
|
free(conn->pgtty);
|
|
|
|
conn->pgtty = strdup(pgtty);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pgtty)
|
|
|
|
goto oom_error;
|
1999-08-31 03:37:37 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
if (login && login[0] != '\0')
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2003-04-28 06:29:12 +02:00
|
|
|
if (conn->pguser)
|
|
|
|
free(conn->pguser);
|
|
|
|
conn->pguser = strdup(login);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pguser)
|
|
|
|
goto oom_error;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
if (pwd && pwd[0] != '\0')
|
|
|
|
{
|
|
|
|
if (conn->pgpass)
|
|
|
|
free(conn->pgpass);
|
2002-08-15 04:56:19 +02:00
|
|
|
conn->pgpass = strdup(pwd);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!conn->pgpass)
|
|
|
|
goto oom_error;
|
2003-04-28 06:29:12 +02:00
|
|
|
}
|
2002-10-25 01:35:55 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
|
|
|
* Compute derived options
|
|
|
|
*/
|
|
|
|
if (!connectOptions2(conn))
|
|
|
|
return conn;
|
2000-08-30 16:54:24 +02:00
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/*
|
|
|
|
* Connect to the database
|
|
|
|
*/
|
|
|
|
if (connectDBStart(conn))
|
|
|
|
(void) connectDBComplete(conn);
|
2000-04-12 19:17:23 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
return conn;
|
2014-11-25 11:55:00 +01:00
|
|
|
|
|
|
|
oom_error:
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return conn;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
/* ----------
|
|
|
|
* connectNoDelay -
|
|
|
|
* Sets the TCP_NODELAY socket option.
|
|
|
|
* Returns 1 if successful, 0 if not.
|
|
|
|
* ----------
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
connectNoDelay(PGconn *conn)
|
|
|
|
{
|
2003-06-12 09:36:51 +02:00
|
|
|
#ifdef TCP_NODELAY
|
1999-11-30 04:08:19 +01:00
|
|
|
int on = 1;
|
|
|
|
|
2000-05-21 23:19:53 +02:00
|
|
|
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_NODELAY,
|
2000-06-14 20:18:01 +02:00
|
|
|
(char *) &on,
|
1999-11-30 04:08:19 +01:00
|
|
|
sizeof(on)) < 0)
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
char sebuf[256];
|
2003-06-14 19:49:54 +02:00
|
|
|
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not set socket to TCP no delay mode: %s\n"),
|
2005-10-15 04:49:52 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
1999-11-30 04:08:19 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2003-06-12 09:36:51 +02:00
|
|
|
#endif
|
1999-11-30 04:08:19 +01:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-12-01 00:20:51 +01:00
|
|
|
/* ----------
|
|
|
|
* connectFailureMessage -
|
|
|
|
* create a friendly error message on connection failure.
|
|
|
|
* ----------
|
|
|
|
*/
|
|
|
|
static void
|
2001-07-15 15:45:04 +02:00
|
|
|
connectFailureMessage(PGconn *conn, int errorno)
|
2000-12-01 00:20:51 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
char sebuf[256];
|
2003-06-12 09:36:51 +02:00
|
|
|
|
2003-07-24 01:30:41 +02:00
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
|
|
|
if (IS_AF_UNIX(conn->raddr.addr.ss_family))
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
char service[NI_MAXHOST];
|
2003-07-24 01:30:41 +02:00
|
|
|
|
2005-10-17 18:24:20 +02:00
|
|
|
pg_getnameinfo_all(&conn->raddr.addr, conn->raddr.salen,
|
|
|
|
NULL, 0,
|
|
|
|
service, sizeof(service),
|
|
|
|
NI_NUMERICSERV);
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2005-10-17 18:24:20 +02:00
|
|
|
libpq_gettext("could not connect to server: %s\n"
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"\tIs the server running locally and accepting\n"
|
|
|
|
"\tconnections on Unix domain socket \"%s\"?\n"),
|
2003-07-24 01:30:41 +02:00
|
|
|
SOCK_STRERROR(errorno, sebuf, sizeof(sebuf)),
|
|
|
|
service);
|
|
|
|
}
|
2000-12-01 00:20:51 +01:00
|
|
|
else
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* HAVE_UNIX_SOCKETS */
|
2003-07-24 01:30:41 +02:00
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
char host_addr[NI_MAXHOST];
|
2011-05-19 21:56:53 +02:00
|
|
|
const char *displayed_host;
|
2016-11-03 14:25:20 +01:00
|
|
|
const char *displayed_port;
|
2010-11-27 01:16:39 +01:00
|
|
|
struct sockaddr_storage *addr = &conn->raddr.addr;
|
2010-11-24 23:04:19 +01:00
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Optionally display the network address with the hostname. This is
|
|
|
|
* useful to distinguish between IPv4 and IPv6 connections.
|
2010-11-24 23:04:19 +01:00
|
|
|
*/
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->connhost[conn->whichhost].type == CHT_HOST_ADDRESS)
|
|
|
|
strlcpy(host_addr, conn->connhost[conn->whichhost].hostaddr, NI_MAXHOST);
|
2010-11-27 01:16:39 +01:00
|
|
|
else if (addr->ss_family == AF_INET)
|
|
|
|
{
|
|
|
|
if (inet_net_ntop(AF_INET,
|
|
|
|
&((struct sockaddr_in *) addr)->sin_addr.s_addr,
|
|
|
|
32,
|
|
|
|
host_addr, sizeof(host_addr)) == NULL)
|
|
|
|
strcpy(host_addr, "???");
|
|
|
|
}
|
|
|
|
#ifdef HAVE_IPV6
|
|
|
|
else if (addr->ss_family == AF_INET6)
|
|
|
|
{
|
|
|
|
if (inet_net_ntop(AF_INET6,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
&((struct sockaddr_in6 *) addr)->sin6_addr.s6_addr,
|
2010-11-27 01:16:39 +01:00
|
|
|
128,
|
|
|
|
host_addr, sizeof(host_addr)) == NULL)
|
|
|
|
strcpy(host_addr, "???");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
else
|
2010-11-24 23:04:19 +01:00
|
|
|
strcpy(host_addr, "???");
|
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/* To which host and port were we actually connecting? */
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->connhost[conn->whichhost].type == CHT_HOST_ADDRESS)
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].hostaddr;
|
|
|
|
else
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].host;
|
2016-11-03 14:25:20 +01:00
|
|
|
displayed_port = conn->connhost[conn->whichhost].port;
|
|
|
|
if (displayed_port == NULL || displayed_port[0] == '\0')
|
|
|
|
displayed_port = DEF_PGPORT_STR;
|
2011-05-19 21:56:53 +02:00
|
|
|
|
2010-12-18 17:25:41 +01:00
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* If the user did not supply an IP address using 'hostaddr', and
|
|
|
|
* 'host' was missing or does not match our lookup, display the
|
|
|
|
* looked-up IP address.
|
2010-12-18 17:25:41 +01:00
|
|
|
*/
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->connhost[conn->whichhost].type != CHT_HOST_ADDRESS &&
|
|
|
|
strcmp(displayed_host, host_addr) != 0)
|
2011-05-19 21:56:53 +02:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not connect to server: %s\n"
|
|
|
|
"\tIs the server running on host \"%s\" (%s) and accepting\n"
|
|
|
|
"\tTCP/IP connections on port %s?\n"),
|
2011-05-19 21:56:53 +02:00
|
|
|
SOCK_STRERROR(errorno, sebuf, sizeof(sebuf)),
|
|
|
|
displayed_host,
|
|
|
|
host_addr,
|
2016-11-03 14:25:20 +01:00
|
|
|
displayed_port);
|
2011-05-19 21:56:53 +02:00
|
|
|
else
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not connect to server: %s\n"
|
|
|
|
"\tIs the server running on host \"%s\" and accepting\n"
|
|
|
|
"\tTCP/IP connections on port %s?\n"),
|
2011-05-19 21:56:53 +02:00
|
|
|
SOCK_STRERROR(errorno, sebuf, sizeof(sebuf)),
|
|
|
|
displayed_host,
|
2016-11-03 14:25:20 +01:00
|
|
|
displayed_port);
|
2003-07-24 01:30:41 +02:00
|
|
|
}
|
2000-12-01 00:20:51 +01:00
|
|
|
}
|
|
|
|
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
/*
|
|
|
|
* Should we use keepalives? Returns 1 if yes, 0 if no, and -1 if
|
|
|
|
* conn->keepalives is set to a value which is not parseable as an
|
|
|
|
* integer.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
useKeepalives(PGconn *conn)
|
|
|
|
{
|
|
|
|
char *ep;
|
|
|
|
int val;
|
|
|
|
|
|
|
|
if (conn->keepalives == NULL)
|
|
|
|
return 1;
|
|
|
|
val = strtol(conn->keepalives, &ep, 10);
|
|
|
|
if (*ep)
|
|
|
|
return -1;
|
|
|
|
return val != 0 ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2010-07-08 12:20:14 +02:00
|
|
|
#ifndef WIN32
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
/*
|
|
|
|
* Set the keepalive idle timer.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
setKeepalivesIdle(PGconn *conn)
|
|
|
|
{
|
2010-07-06 21:19:02 +02:00
|
|
|
int idle;
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
if (conn->keepalives_idle == NULL)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
idle = atoi(conn->keepalives_idle);
|
|
|
|
if (idle < 0)
|
|
|
|
idle = 0;
|
|
|
|
|
2017-06-28 18:30:16 +02:00
|
|
|
#ifdef PG_TCP_KEEPALIVE_IDLE
|
|
|
|
if (setsockopt(conn->sock, IPPROTO_TCP, PG_TCP_KEEPALIVE_IDLE,
|
2010-07-06 23:14:25 +02:00
|
|
|
(char *) &idle, sizeof(idle)) < 0)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
char sebuf[256];
|
2010-07-06 23:14:25 +02:00
|
|
|
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2017-06-28 18:30:16 +02:00
|
|
|
libpq_gettext("setsockopt(%s) failed: %s\n"),
|
|
|
|
PG_TCP_KEEPALIVE_IDLE_STR,
|
2010-07-06 23:14:25 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
|
|
|
return 0;
|
|
|
|
}
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the keepalive interval.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
setKeepalivesInterval(PGconn *conn)
|
|
|
|
{
|
2010-07-06 21:19:02 +02:00
|
|
|
int interval;
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
if (conn->keepalives_interval == NULL)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
interval = atoi(conn->keepalives_interval);
|
|
|
|
if (interval < 0)
|
|
|
|
interval = 0;
|
|
|
|
|
|
|
|
#ifdef TCP_KEEPINTVL
|
|
|
|
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_KEEPINTVL,
|
|
|
|
(char *) &interval, sizeof(interval)) < 0)
|
|
|
|
{
|
2010-07-06 21:19:02 +02:00
|
|
|
char sebuf[256];
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2017-06-28 18:30:16 +02:00
|
|
|
libpq_gettext("setsockopt(%s) failed: %s\n"),
|
|
|
|
"TCP_KEEPINTVL",
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the count of lost keepalive packets that will trigger a connection
|
|
|
|
* break.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
setKeepalivesCount(PGconn *conn)
|
|
|
|
{
|
2010-07-06 21:19:02 +02:00
|
|
|
int count;
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
if (conn->keepalives_count == NULL)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
count = atoi(conn->keepalives_count);
|
|
|
|
if (count < 0)
|
|
|
|
count = 0;
|
|
|
|
|
|
|
|
#ifdef TCP_KEEPCNT
|
|
|
|
if (setsockopt(conn->sock, IPPROTO_TCP, TCP_KEEPCNT,
|
|
|
|
(char *) &count, sizeof(count)) < 0)
|
|
|
|
{
|
2010-07-06 21:19:02 +02:00
|
|
|
char sebuf[256];
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2017-06-28 18:30:16 +02:00
|
|
|
libpq_gettext("setsockopt(%s) failed: %s\n"),
|
|
|
|
"TCP_KEEPCNT",
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
2017-06-28 00:47:57 +02:00
|
|
|
#else /* WIN32 */
|
2010-07-08 18:19:50 +02:00
|
|
|
#ifdef SIO_KEEPALIVE_VALS
|
2010-07-08 12:20:14 +02:00
|
|
|
/*
|
|
|
|
* Enable keepalives and set the keepalive values on Win32,
|
|
|
|
* where they are always set in one batch.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
setKeepalivesWin32(PGconn *conn)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
struct tcp_keepalive ka;
|
|
|
|
DWORD retsize;
|
|
|
|
int idle = 0;
|
|
|
|
int interval = 0;
|
2010-07-08 12:20:14 +02:00
|
|
|
|
|
|
|
if (conn->keepalives_idle)
|
|
|
|
idle = atoi(conn->keepalives_idle);
|
|
|
|
if (idle <= 0)
|
2011-04-10 17:42:00 +02:00
|
|
|
idle = 2 * 60 * 60; /* 2 hours = default */
|
2010-07-08 12:20:14 +02:00
|
|
|
|
|
|
|
if (conn->keepalives_interval)
|
|
|
|
interval = atoi(conn->keepalives_interval);
|
|
|
|
if (interval <= 0)
|
2011-04-10 17:42:00 +02:00
|
|
|
interval = 1; /* 1 second = default */
|
2010-07-08 12:20:14 +02:00
|
|
|
|
|
|
|
ka.onoff = 1;
|
|
|
|
ka.keepalivetime = idle * 1000;
|
|
|
|
ka.keepaliveinterval = interval * 1000;
|
|
|
|
|
|
|
|
if (WSAIoctl(conn->sock,
|
|
|
|
SIO_KEEPALIVE_VALS,
|
|
|
|
(LPVOID) &ka,
|
|
|
|
sizeof(ka),
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
&retsize,
|
|
|
|
NULL,
|
|
|
|
NULL)
|
|
|
|
!= 0)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("WSAIoctl(SIO_KEEPALIVE_VALS) failed: %ui\n"),
|
2010-07-08 12:20:14 +02:00
|
|
|
WSAGetLastError());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* SIO_KEEPALIVE_VALS */
|
|
|
|
#endif /* WIN32 */
|
2000-12-01 00:20:51 +01:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
/* ----------
|
|
|
|
* connectDBStart -
|
2003-06-08 19:43:00 +02:00
|
|
|
* Begin the process of making a connection to the backend.
|
|
|
|
*
|
1999-11-30 04:08:19 +01:00
|
|
|
* Returns 1 if successful, 0 if not.
|
|
|
|
* ----------
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
connectDBStart(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2012-11-30 01:57:01 +01:00
|
|
|
char portstr[MAXPGPATH];
|
2003-01-06 04:18:27 +01:00
|
|
|
int ret;
|
2016-11-03 14:25:20 +01:00
|
|
|
int i;
|
2004-08-29 07:07:03 +02:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
if (!conn)
|
|
|
|
return 0;
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2006-02-13 23:33:57 +01:00
|
|
|
if (!conn->options_valid)
|
|
|
|
goto connect_errReturn;
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
/* Ensure our buffers are empty */
|
|
|
|
conn->inStart = conn->inCursor = conn->inEnd = 0;
|
|
|
|
conn->outCount = 0;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2016-11-03 14:25:20 +01:00
|
|
|
* Look up socket addresses for each possible host using
|
|
|
|
* pg_getaddrinfo_all.
|
2003-01-06 04:18:27 +01:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
for (i = 0; i < conn->nconnhost; ++i)
|
2009-09-27 05:43:10 +02:00
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
pg_conn_host *ch = &conn->connhost[i];
|
|
|
|
struct addrinfo hint;
|
|
|
|
int thisport;
|
|
|
|
|
|
|
|
/* Initialize hint structure */
|
|
|
|
MemSet(&hint, 0, sizeof(hint));
|
|
|
|
hint.ai_socktype = SOCK_STREAM;
|
|
|
|
hint.ai_family = AF_UNSPEC;
|
|
|
|
|
|
|
|
/* Figure out the port number we're going to use. */
|
2017-07-10 11:28:57 +02:00
|
|
|
if (ch->port == NULL || ch->port[0] == '\0')
|
2016-11-03 14:25:20 +01:00
|
|
|
thisport = DEF_PGPORT;
|
|
|
|
else
|
2009-09-27 05:43:10 +02:00
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
thisport = atoi(ch->port);
|
|
|
|
if (thisport < 1 || thisport > 65535)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid port number: \"%s\"\n"),
|
2016-11-03 14:25:20 +01:00
|
|
|
ch->port);
|
|
|
|
conn->options_valid = false;
|
|
|
|
goto connect_errReturn;
|
|
|
|
}
|
2009-09-27 05:43:10 +02:00
|
|
|
}
|
2016-11-03 14:25:20 +01:00
|
|
|
snprintf(portstr, sizeof(portstr), "%d", thisport);
|
2003-01-06 04:18:27 +01:00
|
|
|
|
2017-06-09 12:05:41 +02:00
|
|
|
/* Use pg_getaddrinfo_all() to resolve the address */
|
2017-06-09 20:50:35 +02:00
|
|
|
ret = 1;
|
2016-11-03 14:25:20 +01:00
|
|
|
switch (ch->type)
|
|
|
|
{
|
|
|
|
case CHT_HOST_NAME:
|
2017-06-09 12:05:41 +02:00
|
|
|
ret = pg_getaddrinfo_all(ch->host, portstr, &hint, &ch->addrlist);
|
|
|
|
if (ret || !ch->addrlist)
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("could not translate host name \"%s\" to address: %s\n"),
|
|
|
|
ch->host, gai_strerror(ret));
|
2016-11-03 14:25:20 +01:00
|
|
|
break;
|
2017-06-09 12:05:41 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
case CHT_HOST_ADDRESS:
|
|
|
|
hint.ai_flags = AI_NUMERICHOST;
|
2017-07-10 11:28:57 +02:00
|
|
|
ret = pg_getaddrinfo_all(ch->hostaddr, portstr, &hint, &ch->addrlist);
|
2017-06-09 12:05:41 +02:00
|
|
|
if (ret || !ch->addrlist)
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("could not parse network address \"%s\": %s\n"),
|
|
|
|
ch->host, gai_strerror(ret));
|
2016-11-03 14:25:20 +01:00
|
|
|
break;
|
2017-06-09 12:05:41 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
case CHT_UNIX_SOCKET:
|
2004-12-29 00:17:54 +01:00
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
2016-11-03 14:25:20 +01:00
|
|
|
hint.ai_family = AF_UNIX;
|
|
|
|
UNIXSOCK_PATH(portstr, thisport, ch->host);
|
|
|
|
if (strlen(portstr) >= UNIXSOCK_PATH_BUFLEN)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("Unix-domain socket path \"%s\" is too long (maximum %d bytes)\n"),
|
2017-05-17 22:31:56 +02:00
|
|
|
portstr,
|
|
|
|
(int) (UNIXSOCK_PATH_BUFLEN - 1));
|
2016-11-03 14:25:20 +01:00
|
|
|
conn->options_valid = false;
|
|
|
|
goto connect_errReturn;
|
|
|
|
}
|
2017-06-09 12:05:41 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NULL hostname tells pg_getaddrinfo_all to parse the service
|
|
|
|
* name as a Unix-domain socket path.
|
|
|
|
*/
|
|
|
|
ret = pg_getaddrinfo_all(NULL, portstr, &hint, &ch->addrlist);
|
|
|
|
if (ret || !ch->addrlist)
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("could not translate Unix-domain socket path \"%s\" to address: %s\n"),
|
|
|
|
portstr, gai_strerror(ret));
|
|
|
|
break;
|
2016-11-03 14:25:20 +01:00
|
|
|
#else
|
|
|
|
Assert(false);
|
2017-06-09 12:05:41 +02:00
|
|
|
conn->options_valid = false;
|
|
|
|
goto connect_errReturn;
|
2016-11-03 14:25:20 +01:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
if (ret || !ch->addrlist)
|
2012-11-30 01:57:01 +01:00
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
if (ch->addrlist)
|
|
|
|
{
|
|
|
|
pg_freeaddrinfo_all(hint.ai_family, ch->addrlist);
|
|
|
|
ch->addrlist = NULL;
|
|
|
|
}
|
2012-11-30 01:57:01 +01:00
|
|
|
conn->options_valid = false;
|
|
|
|
goto connect_errReturn;
|
|
|
|
}
|
2002-12-06 05:37:05 +01:00
|
|
|
}
|
|
|
|
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
#ifdef USE_SSL
|
|
|
|
/* setup values based on SSL mode */
|
2003-08-04 02:43:34 +02:00
|
|
|
if (conn->sslmode[0] == 'd') /* "disable" */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->allow_ssl_try = false;
|
2003-08-04 02:43:34 +02:00
|
|
|
else if (conn->sslmode[0] == 'a') /* "allow" */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->wait_ssl_try = true;
|
|
|
|
#endif
|
|
|
|
|
2003-02-14 02:24:26 +01:00
|
|
|
/*
|
2003-06-08 19:43:00 +02:00
|
|
|
* Set up to try to connect, with protocol 3.0 as the first attempt.
|
2003-02-14 02:24:26 +01:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
conn->whichhost = 0;
|
|
|
|
conn->addr_cur = conn->connhost[0].addrlist;
|
2003-08-04 02:43:34 +02:00
|
|
|
conn->pversion = PG_PROTOCOL(3, 0);
|
2009-12-02 05:38:35 +01:00
|
|
|
conn->send_appname = true;
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* The code for processing CONNECTION_NEEDED state is in PQconnectPoll(),
|
|
|
|
* so that it can easily be re-executed if needed again during the
|
|
|
|
* asynchronous startup process. However, we must run it once here,
|
|
|
|
* because callers expect a success return from this routine to mean that
|
|
|
|
* we are in PGRES_POLLING_WRITING connection state.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
if (PQconnectPoll(conn) == PGRES_POLLING_WRITING)
|
|
|
|
return 1;
|
1998-01-26 02:42:53 +01:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
connect_errReturn:
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
1999-11-30 04:08:19 +01:00
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return 0;
|
|
|
|
}
|
1998-01-26 02:42:53 +01:00
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
1999-11-30 04:08:19 +01:00
|
|
|
* connectDBComplete
|
|
|
|
*
|
|
|
|
* Block and complete a connection.
|
|
|
|
*
|
|
|
|
* Returns 1 on success, 0 on failure.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
connectDBComplete(PGconn *conn)
|
|
|
|
{
|
2000-01-16 22:18:52 +01:00
|
|
|
PostgresPollingStatusType flag = PGRES_POLLING_WRITING;
|
2002-12-19 20:30:24 +01:00
|
|
|
time_t finish_time = ((time_t) -1);
|
2017-05-19 22:19:51 +02:00
|
|
|
int timeout = 0;
|
2002-08-17 14:33:18 +02:00
|
|
|
|
2000-01-16 22:18:52 +01:00
|
|
|
if (conn == NULL || conn->status == CONNECTION_BAD)
|
|
|
|
return 0;
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2002-09-04 22:31:48 +02:00
|
|
|
/*
|
2002-10-25 01:35:55 +02:00
|
|
|
* Set up a time limit, if connect_timeout isn't zero.
|
2002-09-04 22:31:48 +02:00
|
|
|
*/
|
|
|
|
if (conn->connect_timeout != NULL)
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2017-05-19 22:19:51 +02:00
|
|
|
timeout = atoi(conn->connect_timeout);
|
2002-10-25 01:35:55 +02:00
|
|
|
if (timeout > 0)
|
2002-08-27 16:49:52 +02:00
|
|
|
{
|
2002-12-19 20:30:24 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Rounding could cause connection to fail; need at least 2 secs
|
2002-12-19 20:30:24 +01:00
|
|
|
*/
|
2002-10-25 01:35:55 +02:00
|
|
|
if (timeout < 2)
|
|
|
|
timeout = 2;
|
|
|
|
/* calculate the finish time based on start + timeout */
|
|
|
|
finish_time = time(NULL) + timeout;
|
2002-08-27 16:49:52 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-10-25 01:35:55 +02:00
|
|
|
for (;;)
|
2002-08-27 16:49:52 +02:00
|
|
|
{
|
2017-05-19 22:19:51 +02:00
|
|
|
int ret = 0;
|
|
|
|
|
2000-01-16 22:18:52 +01:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Wait, if necessary. Note that the initial state (just after
|
2005-10-15 04:49:52 +02:00
|
|
|
* PQconnectStart) is to wait for the socket to select for writing.
|
2000-01-16 22:18:52 +01:00
|
|
|
*/
|
2000-01-14 06:33:15 +01:00
|
|
|
switch (flag)
|
1998-01-26 02:42:53 +01:00
|
|
|
{
|
1999-11-30 04:08:19 +01:00
|
|
|
case PGRES_POLLING_OK:
|
2009-06-11 16:49:15 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset stored error messages since we now have a working
|
|
|
|
* connection
|
|
|
|
*/
|
2008-10-27 10:42:31 +01:00
|
|
|
resetPQExpBuffer(&conn->errorMessage);
|
2000-01-14 06:33:15 +01:00
|
|
|
return 1; /* success! */
|
2000-04-12 19:17:23 +02:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
case PGRES_POLLING_READING:
|
2017-05-19 22:19:51 +02:00
|
|
|
ret = pqWaitTimed(1, 0, conn, finish_time);
|
|
|
|
if (ret == -1)
|
2000-01-14 06:33:15 +01:00
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return 0;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PGRES_POLLING_WRITING:
|
2017-05-19 22:19:51 +02:00
|
|
|
ret = pqWaitTimed(0, 1, conn, finish_time);
|
|
|
|
if (ret == -1)
|
2000-01-14 06:33:15 +01:00
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return 0;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
/* Just in case we failed to set it in PQconnectPoll */
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return 0;
|
1998-01-26 02:42:53 +01:00
|
|
|
}
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2017-06-13 19:05:59 +02:00
|
|
|
if (ret == 1) /* connect_timeout elapsed */
|
2017-05-19 22:19:51 +02:00
|
|
|
{
|
2017-06-13 19:05:59 +02:00
|
|
|
/*
|
|
|
|
* If there are no more hosts, return (the error message is
|
|
|
|
* already set)
|
|
|
|
*/
|
2017-05-19 22:19:51 +02:00
|
|
|
if (++conn->whichhost >= conn->nconnhost)
|
|
|
|
{
|
|
|
|
conn->whichhost = 0;
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
return 0;
|
|
|
|
}
|
2017-06-13 19:05:59 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Attempt connection to the next host, starting the
|
|
|
|
* connect_timeout timer
|
|
|
|
*/
|
2017-05-19 22:19:51 +02:00
|
|
|
pqDropConnection(conn, true);
|
|
|
|
conn->addr_cur = conn->connhost[conn->whichhost].addrlist;
|
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
if (conn->connect_timeout != NULL)
|
|
|
|
finish_time = time(NULL) + timeout;
|
|
|
|
}
|
|
|
|
|
2000-01-16 22:18:52 +01:00
|
|
|
/*
|
|
|
|
* Now try to advance the state machine.
|
|
|
|
*/
|
|
|
|
flag = PQconnectPoll(conn);
|
2000-01-14 06:33:15 +01:00
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
2016-12-05 20:09:54 +01:00
|
|
|
/*
|
|
|
|
* This subroutine saves conn->errorMessage, which will be restored back by
|
|
|
|
* restoreErrorMessage subroutine.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
saveErrorMessage(PGconn *conn, PQExpBuffer savedMessage)
|
|
|
|
{
|
|
|
|
initPQExpBuffer(savedMessage);
|
|
|
|
if (PQExpBufferBroken(savedMessage))
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
appendPQExpBufferStr(savedMessage,
|
|
|
|
conn->errorMessage.data);
|
|
|
|
resetPQExpBuffer(&conn->errorMessage);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Restores saved error messages back to conn->errorMessage.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
restoreErrorMessage(PGconn *conn, PQExpBuffer savedMessage)
|
|
|
|
{
|
|
|
|
appendPQExpBufferStr(savedMessage, conn->errorMessage.data);
|
|
|
|
resetPQExpBuffer(&conn->errorMessage);
|
|
|
|
appendPQExpBufferStr(&conn->errorMessage, savedMessage->data);
|
|
|
|
termPQExpBuffer(savedMessage);
|
|
|
|
}
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
/* ----------------
|
|
|
|
* PQconnectPoll
|
|
|
|
*
|
|
|
|
* Poll an asynchronous connection.
|
|
|
|
*
|
|
|
|
* Returns a PostgresPollingStatusType.
|
2002-08-27 18:21:51 +02:00
|
|
|
* Before calling this function, use select(2) to determine when data
|
|
|
|
* has arrived..
|
2000-04-12 19:17:23 +02:00
|
|
|
*
|
1999-11-30 04:08:19 +01:00
|
|
|
* You must call PQfinish whether or not this fails.
|
|
|
|
*
|
|
|
|
* This function and PQconnectStart are intended to allow connections to be
|
|
|
|
* made without blocking the execution of your program on remote I/O. However,
|
|
|
|
* there are a number of caveats:
|
|
|
|
*
|
2000-04-12 19:17:23 +02:00
|
|
|
* o If you call PQtrace, ensure that the stream object into which you trace
|
|
|
|
* will not block.
|
|
|
|
* o If you do not supply an IP address for the remote host (i.e. you
|
2003-06-08 19:43:00 +02:00
|
|
|
* supply a host name instead) then PQconnectStart will block on
|
2014-05-06 18:12:18 +02:00
|
|
|
* gethostbyname. You will be fine if using Unix sockets (i.e. by
|
2000-04-12 19:17:23 +02:00
|
|
|
* supplying neither a host name nor a host address).
|
|
|
|
* o If your backend wants to use Kerberos authentication then you must
|
|
|
|
* supply both a host name and a host address, otherwise this function
|
|
|
|
* may block on gethostname.
|
1999-11-30 04:08:19 +01:00
|
|
|
*
|
2000-01-14 06:33:15 +01:00
|
|
|
* ----------------
|
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
PostgresPollingStatusType
|
|
|
|
PQconnectPoll(PGconn *conn)
|
|
|
|
{
|
|
|
|
PGresult *res;
|
2003-06-14 19:49:54 +02:00
|
|
|
char sebuf[256];
|
2009-07-24 19:58:31 +02:00
|
|
|
int optval;
|
2016-12-05 20:09:54 +01:00
|
|
|
PQExpBufferData savedMessage;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
if (conn == NULL)
|
|
|
|
return PGRES_POLLING_FAILED;
|
|
|
|
|
|
|
|
/* Get the new data */
|
|
|
|
switch (conn->status)
|
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We really shouldn't have been polled in these two cases, but we
|
|
|
|
* can handle it.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
case CONNECTION_BAD:
|
|
|
|
return PGRES_POLLING_FAILED;
|
|
|
|
case CONNECTION_OK:
|
|
|
|
return PGRES_POLLING_OK;
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/* These are reading states */
|
1999-11-30 04:08:19 +01:00
|
|
|
case CONNECTION_AWAITING_RESPONSE:
|
|
|
|
case CONNECTION_AUTH_OK:
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
|
|
|
/* Load waiting data */
|
|
|
|
int n = pqReadData(conn);
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
if (n < 0)
|
|
|
|
goto error_return;
|
|
|
|
if (n == 0)
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/* These are writing states, so we just proceed. */
|
1999-11-30 04:08:19 +01:00
|
|
|
case CONNECTION_STARTED:
|
|
|
|
case CONNECTION_MADE:
|
2000-04-12 19:17:23 +02:00
|
|
|
break;
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
/* We allow pqSetenvPoll to decide whether to proceed. */
|
2003-06-08 19:43:00 +02:00
|
|
|
case CONNECTION_SETENV:
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Special cases: proceed without waiting. */
|
|
|
|
case CONNECTION_SSL_STARTUP:
|
|
|
|
case CONNECTION_NEEDED:
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
case CONNECTION_CHECK_WRITABLE:
|
2017-02-15 17:03:30 +01:00
|
|
|
case CONNECTION_CONSUME:
|
2003-06-08 19:43:00 +02:00
|
|
|
break;
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
default:
|
2013-11-18 17:29:01 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
libpq_gettext(
|
|
|
|
"invalid connection state, "
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"probably indicative of memory corruption\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
));
|
1999-11-30 04:08:19 +01:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
keep_going: /* We will come back to here until there is
|
|
|
|
* nothing left to do. */
|
2000-04-12 19:17:23 +02:00
|
|
|
switch (conn->status)
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
case CONNECTION_NEEDED:
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Try to initiate a connection to one of the addresses
|
2005-10-17 18:24:20 +02:00
|
|
|
* returned by pg_getaddrinfo_all(). conn->addr_cur is the
|
2010-11-26 17:52:03 +01:00
|
|
|
* next one to try. We fail when we run out of addresses.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
for (;;)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
struct addrinfo *addr_cur;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Advance to next possible host, if we've tried all of
|
|
|
|
* the addresses for the current host.
|
|
|
|
*/
|
|
|
|
if (conn->addr_cur == NULL)
|
|
|
|
{
|
|
|
|
if (++conn->whichhost >= conn->nconnhost)
|
|
|
|
{
|
|
|
|
conn->whichhost = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
conn->addr_cur =
|
|
|
|
conn->connhost[conn->whichhost].addrlist;
|
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/* Remember current address for possible error msg */
|
2016-11-03 14:25:20 +01:00
|
|
|
addr_cur = conn->addr_cur;
|
2003-06-20 06:09:12 +02:00
|
|
|
memcpy(&conn->raddr.addr, addr_cur->ai_addr,
|
2003-06-08 19:43:00 +02:00
|
|
|
addr_cur->ai_addrlen);
|
2003-06-20 06:09:12 +02:00
|
|
|
conn->raddr.salen = addr_cur->ai_addrlen;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
2014-04-17 01:46:51 +02:00
|
|
|
conn->sock = socket(addr_cur->ai_family, SOCK_STREAM, 0);
|
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* ignore socket() failure if we have more addresses
|
|
|
|
* to try
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
if (addr_cur->ai_next != NULL ||
|
|
|
|
conn->whichhost + 1 < conn->nconnhost)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
|
|
|
continue;
|
|
|
|
}
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not create socket: %s\n"),
|
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2003-06-08 19:43:00 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Select socket options: no delay of outgoing data for
|
|
|
|
* TCP sockets, nonblock mode, close-on-exec. Fail if any
|
|
|
|
* of this fails.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2003-06-12 09:36:51 +02:00
|
|
|
if (!IS_AF_UNIX(addr_cur->ai_family))
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
if (!connectNoDelay(conn))
|
2003-06-12 09:36:51 +02:00
|
|
|
{
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2003-06-12 09:36:51 +02:00
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
|
|
|
continue;
|
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
}
|
2005-03-25 01:34:31 +01:00
|
|
|
if (!pg_set_noblock(conn->sock))
|
2003-06-12 09:36:51 +02:00
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2013-04-19 05:35:19 +02:00
|
|
|
libpq_gettext("could not set socket to nonblocking mode: %s\n"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2004-10-21 22:23:19 +02:00
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-04-22 08:06:16 +02:00
|
|
|
#ifdef F_SETFD
|
2004-10-21 22:23:19 +02:00
|
|
|
if (fcntl(conn->sock, F_SETFD, FD_CLOEXEC) == -1)
|
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2004-10-21 22:23:19 +02:00
|
|
|
libpq_gettext("could not set socket to close-on-exec mode: %s\n"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2003-06-12 09:36:51 +02:00
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
|
|
|
continue;
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* F_SETFD */
|
2003-08-04 02:43:34 +02:00
|
|
|
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
if (!IS_AF_UNIX(addr_cur->ai_family))
|
|
|
|
{
|
2011-04-19 13:54:48 +02:00
|
|
|
#ifndef WIN32
|
2010-07-06 21:19:02 +02:00
|
|
|
int on = 1;
|
2011-04-19 13:54:48 +02:00
|
|
|
#endif
|
2010-07-06 21:19:02 +02:00
|
|
|
int usekeepalives = useKeepalives(conn);
|
|
|
|
int err = 0;
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
if (usekeepalives < 0)
|
|
|
|
{
|
2013-11-18 17:29:01 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
libpq_gettext("keepalives parameter must be an integer\n"));
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
err = 1;
|
|
|
|
}
|
|
|
|
else if (usekeepalives == 0)
|
|
|
|
{
|
|
|
|
/* Do nothing */
|
|
|
|
}
|
2010-07-08 12:20:14 +02:00
|
|
|
#ifndef WIN32
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
else if (setsockopt(conn->sock,
|
|
|
|
SOL_SOCKET, SO_KEEPALIVE,
|
|
|
|
(char *) &on, sizeof(on)) < 0)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2017-06-28 18:30:16 +02:00
|
|
|
libpq_gettext("setsockopt(%s) failed: %s\n"),
|
|
|
|
"SO_KEEPALIVE",
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
err = 1;
|
|
|
|
}
|
|
|
|
else if (!setKeepalivesIdle(conn)
|
|
|
|
|| !setKeepalivesInterval(conn)
|
|
|
|
|| !setKeepalivesCount(conn))
|
|
|
|
err = 1;
|
2011-04-10 17:42:00 +02:00
|
|
|
#else /* WIN32 */
|
2010-07-08 18:19:50 +02:00
|
|
|
#ifdef SIO_KEEPALIVE_VALS
|
2010-07-08 12:20:14 +02:00
|
|
|
else if (!setKeepalivesWin32(conn))
|
|
|
|
err = 1;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* SIO_KEEPALIVE_VALS */
|
|
|
|
#endif /* WIN32 */
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
|
|
|
|
if (err)
|
|
|
|
{
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-24 19:58:31 +02:00
|
|
|
/*----------
|
|
|
|
* We have three methods of blocking SIGPIPE during
|
|
|
|
* send() calls to this socket:
|
|
|
|
*
|
2010-02-26 03:01:40 +01:00
|
|
|
* - setsockopt(sock, SO_NOSIGPIPE)
|
|
|
|
* - send(sock, ..., MSG_NOSIGNAL)
|
|
|
|
* - setting the signal mask to SIG_IGN during send()
|
2009-07-24 19:58:31 +02:00
|
|
|
*
|
|
|
|
* The third method requires three syscalls per send,
|
|
|
|
* so we prefer either of the first two, but they are
|
|
|
|
* less portable. The state is tracked in the following
|
|
|
|
* members of PGconn:
|
|
|
|
*
|
|
|
|
* conn->sigpipe_so - we have set up SO_NOSIGPIPE
|
|
|
|
* conn->sigpipe_flag - we're specifying MSG_NOSIGNAL
|
|
|
|
*
|
|
|
|
* If we can use SO_NOSIGPIPE, then set sigpipe_so here
|
|
|
|
* and we're done. Otherwise, set sigpipe_flag so that
|
|
|
|
* we will try MSG_NOSIGNAL on sends. If we get an error
|
|
|
|
* with MSG_NOSIGNAL, we'll clear that flag and revert to
|
|
|
|
* signal masking.
|
|
|
|
*----------
|
|
|
|
*/
|
|
|
|
conn->sigpipe_so = false;
|
|
|
|
#ifdef MSG_NOSIGNAL
|
|
|
|
conn->sigpipe_flag = true;
|
|
|
|
#else
|
|
|
|
conn->sigpipe_flag = false;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* MSG_NOSIGNAL */
|
2009-07-24 19:58:31 +02:00
|
|
|
|
|
|
|
#ifdef SO_NOSIGPIPE
|
|
|
|
optval = 1;
|
|
|
|
if (setsockopt(conn->sock, SOL_SOCKET, SO_NOSIGPIPE,
|
|
|
|
(char *) &optval, sizeof(optval)) == 0)
|
|
|
|
{
|
|
|
|
conn->sigpipe_so = true;
|
|
|
|
conn->sigpipe_flag = false;
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* SO_NOSIGPIPE */
|
2009-07-24 19:58:31 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Start/make connection. This should not block, since we
|
|
|
|
* are in nonblock mode. If it does, well, too bad.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
if (connect(conn->sock, addr_cur->ai_addr,
|
|
|
|
addr_cur->ai_addrlen) < 0)
|
|
|
|
{
|
|
|
|
if (SOCK_ERRNO == EINPROGRESS ||
|
Expect EWOULDBLOCK from a non-blocking connect() call only on Windows.
On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is
*not* a success return, at least not on Linux. We need to treat it as a
failure to avoid giving a misleading error message. Per the Single Unix
Spec, only EINPROGRESS and EINTR returns indicate that the connection
attempt is in progress.
On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected
case. We must accept EINPROGRESS as well because Cygwin will return that,
and it doesn't seem worth distinguishing Cygwin from native Windows here.
It's not very clear whether EINTR can occur on Windows, but let's leave
that part of the logic alone in the absence of concrete trouble reports.
Also, remove the test for errno == 0, effectively reverting commit
da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko;
or at best it might have been a workaround for a platform-specific bug,
which we can hope is gone now thirteen years later. In any case, since
libpq makes no effort to reset errno to zero before calling connect(),
it seems unlikely that that test has ever reliably done anything useful.
Andres Freund and Tom Lane
2013-06-27 18:36:44 +02:00
|
|
|
#ifdef WIN32
|
2003-06-08 19:43:00 +02:00
|
|
|
SOCK_ERRNO == EWOULDBLOCK ||
|
Expect EWOULDBLOCK from a non-blocking connect() call only on Windows.
On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is
*not* a success return, at least not on Linux. We need to treat it as a
failure to avoid giving a misleading error message. Per the Single Unix
Spec, only EINPROGRESS and EINTR returns indicate that the connection
attempt is in progress.
On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected
case. We must accept EINPROGRESS as well because Cygwin will return that,
and it doesn't seem worth distinguishing Cygwin from native Windows here.
It's not very clear whether EINTR can occur on Windows, but let's leave
that part of the logic alone in the absence of concrete trouble reports.
Also, remove the test for errno == 0, effectively reverting commit
da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko;
or at best it might have been a workaround for a platform-specific bug,
which we can hope is gone now thirteen years later. In any case, since
libpq makes no effort to reset errno to zero before calling connect(),
it seems unlikely that that test has ever reliably done anything useful.
Andres Freund and Tom Lane
2013-06-27 18:36:44 +02:00
|
|
|
#endif
|
|
|
|
SOCK_ERRNO == EINTR)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* This is fine - we're in non-blocking mode, and
|
|
|
|
* the connection is in progress. Tell caller to
|
|
|
|
* wait for write-ready on socket.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
conn->status = CONNECTION_STARTED;
|
|
|
|
return PGRES_POLLING_WRITING;
|
|
|
|
}
|
|
|
|
/* otherwise, trouble */
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Hm, we're connected already --- seems the "nonblock
|
|
|
|
* connection" wasn't. Advance the state machine and
|
|
|
|
* go do the next stuff.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
conn->status = CONNECTION_STARTED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* This connection failed --- set up error report, then
|
|
|
|
* close socket (do it this way in case close() affects
|
2014-05-06 18:12:18 +02:00
|
|
|
* the value of errno...). We will ignore the connect()
|
2005-10-15 04:49:52 +02:00
|
|
|
* failure and keep going if there are more addresses.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
connectFailureMessage(conn, SOCK_ERRNO);
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
|
|
|
* Try the next address, if any.
|
|
|
|
*/
|
|
|
|
conn->addr_cur = addr_cur->ai_next;
|
2003-08-04 02:43:34 +02:00
|
|
|
} /* loop over addresses */
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/*
|
2017-03-14 16:38:30 +01:00
|
|
|
* Oops, no more addresses. An appropriate error message is
|
2005-10-15 04:49:52 +02:00
|
|
|
* already set up, so just set the right status.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
case CONNECTION_STARTED:
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
ACCEPT_TYPE_ARG3 optlen = sizeof(optval);
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Write ready, since we've made it here, so the connection
|
|
|
|
* has been made ... or has failed.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2000-01-14 06:33:15 +01:00
|
|
|
/*
|
2000-04-12 19:17:23 +02:00
|
|
|
* Now check (using getsockopt) that there is not an error
|
|
|
|
* state waiting for us on the socket.
|
2000-01-14 06:33:15 +01:00
|
|
|
*/
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
|
2000-06-14 20:18:01 +02:00
|
|
|
(char *) &optval, &optlen) == -1)
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not get socket error status: %s\n"),
|
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
else if (optval != 0)
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* When using a nonblocking connect, we will typically see
|
|
|
|
* connect failures at this point, so provide a friendly
|
|
|
|
* error message.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
2001-07-15 15:45:04 +02:00
|
|
|
connectFailureMessage(conn, optval);
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If more addresses remain, keep trying, just as in the
|
|
|
|
* case where connect() returned failure immediately.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->addr_cur->ai_next != NULL ||
|
|
|
|
conn->whichhost + 1 < conn->nconnhost)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
conn->addr_cur = conn->addr_cur->ai_next;
|
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fill in the client address */
|
2003-06-12 09:36:51 +02:00
|
|
|
conn->laddr.salen = sizeof(conn->laddr.addr);
|
2003-08-04 02:43:34 +02:00
|
|
|
if (getsockname(conn->sock,
|
2017-06-21 20:39:04 +02:00
|
|
|
(struct sockaddr *) &conn->laddr.addr,
|
2003-08-04 02:43:34 +02:00
|
|
|
&conn->laddr.salen) < 0)
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2003-08-04 02:43:34 +02:00
|
|
|
libpq_gettext("could not get client address from socket: %s\n"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
|
|
|
* Make sure we can write before advancing to next step.
|
|
|
|
*/
|
2000-04-12 19:17:23 +02:00
|
|
|
conn->status = CONNECTION_MADE;
|
|
|
|
return PGRES_POLLING_WRITING;
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
case CONNECTION_MADE:
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
char *startpacket;
|
|
|
|
int packetlen;
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2011-06-02 19:05:01 +02:00
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
2011-06-09 20:32:50 +02:00
|
|
|
|
Replace use of credential control messages with getsockopt(LOCAL_PEERCRED).
It turns out the reason we hadn't found out about the portability issues
with our credential-control-message code is that almost no modern platforms
use that code at all; the ones that used to need it now offer getpeereid(),
which we choose first. The last holdout was NetBSD, and they added
getpeereid() as of 5.0. So far as I can tell, the only live platform on
which that code was being exercised was Debian/kFreeBSD, ie, FreeBSD kernel
with Linux userland --- since glibc doesn't provide getpeereid(), we fell
back to the control message code. However, the FreeBSD kernel provides a
LOCAL_PEERCRED socket parameter that's functionally equivalent to Linux's
SO_PEERCRED. That is both much simpler to use than control messages, and
superior because it doesn't require receiving a message from the other end
at just the right time.
Therefore, add code to use LOCAL_PEERCRED when necessary, and rip out all
the credential-control-message code in the backend. (libpq still has such
code so that it can still talk to pre-9.1 servers ... but eventually we can
get rid of it there too.) Clean up related autoconf probes, too.
This means that libpq's requirepeer parameter now works on exactly the same
platforms where the backend supports peer authentication, so adjust the
documentation accordingly.
2011-05-31 22:10:46 +02:00
|
|
|
/*
|
|
|
|
* Implement requirepeer check, if requested and it's a
|
|
|
|
* Unix-domain socket.
|
|
|
|
*/
|
|
|
|
if (conn->requirepeer && conn->requirepeer[0] &&
|
|
|
|
IS_AF_UNIX(conn->raddr.addr.ss_family))
|
2010-07-18 13:37:26 +02:00
|
|
|
{
|
|
|
|
char pwdbuf[BUFSIZ];
|
|
|
|
struct passwd pass_buf;
|
|
|
|
struct passwd *pass;
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
int passerr;
|
2010-07-18 13:37:26 +02:00
|
|
|
uid_t uid;
|
|
|
|
gid_t gid;
|
|
|
|
|
|
|
|
errno = 0;
|
2010-07-18 18:42:20 +02:00
|
|
|
if (getpeereid(conn->sock, &uid, &gid) != 0)
|
2010-07-18 13:37:26 +02:00
|
|
|
{
|
2011-06-09 20:32:50 +02:00
|
|
|
/*
|
|
|
|
* Provide special error message if getpeereid is a
|
|
|
|
* stub
|
|
|
|
*/
|
2011-06-02 19:05:01 +02:00
|
|
|
if (errno == ENOSYS)
|
2013-11-18 17:29:01 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
libpq_gettext("requirepeer parameter is not supported on this platform\n"));
|
2011-06-02 19:05:01 +02:00
|
|
|
else
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("could not get peer credentials: %s\n"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
pqStrerror(errno, sebuf, sizeof(sebuf)));
|
2010-07-18 13:37:26 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
passerr = pqGetpwuid(uid, &pass_buf, pwdbuf, sizeof(pwdbuf), &pass);
|
2010-07-18 13:37:26 +02:00
|
|
|
if (pass == NULL)
|
|
|
|
{
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
if (passerr != 0)
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("could not look up local user ID %d: %s\n"),
|
|
|
|
(int) uid,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
pqStrerror(passerr, sebuf, sizeof(sebuf)));
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
else
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("local user with ID %d does not exist\n"),
|
|
|
|
(int) uid);
|
2010-07-18 13:37:26 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(pass->pw_name, conn->requirepeer) != 0)
|
|
|
|
{
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2010-07-18 19:08:11 +02:00
|
|
|
libpq_gettext("requirepeer specifies \"%s\", but actual peer user name is \"%s\"\n"),
|
|
|
|
conn->requirepeer, pass->pw_name);
|
2010-07-18 13:37:26 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* HAVE_UNIX_SOCKETS */
|
2010-07-18 13:37:26 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
#ifdef USE_SSL
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If SSL is enabled and we haven't already got it running,
|
|
|
|
* request it instead of sending the startup message.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2003-07-24 01:30:41 +02:00
|
|
|
if (IS_AF_UNIX(conn->raddr.addr.ss_family))
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
/* Don't bother requesting SSL over a Unix socket */
|
|
|
|
conn->allow_ssl_try = false;
|
|
|
|
}
|
2003-08-01 23:27:27 +02:00
|
|
|
if (conn->allow_ssl_try && !conn->wait_ssl_try &&
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
!conn->ssl_in_use)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
ProtocolVersion pv;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send the SSL request packet.
|
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* Theoretically, this could block, but it really
|
|
|
|
* shouldn't since we only got here if the socket is
|
|
|
|
* write-ready.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
2017-10-02 00:36:14 +02:00
|
|
|
pv = pg_hton32(NEGOTIATE_SSL_CODE);
|
2003-06-08 19:43:00 +02:00
|
|
|
if (pqPacketSend(conn, 0, &pv, sizeof(pv)) != STATUS_OK)
|
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2003-06-08 19:43:00 +02:00
|
|
|
libpq_gettext("could not send SSL negotiation packet: %s\n"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2003-06-08 19:43:00 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
/* Ok, wait for response */
|
|
|
|
conn->status = CONNECTION_SSL_STARTUP;
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_SSL */
|
2003-06-08 19:43:00 +02:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2003-04-18 00:26:02 +02:00
|
|
|
* Build the startup packet.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
|
|
|
|
startpacket = pqBuildStartupPacket3(conn, &packetlen,
|
2005-10-15 04:49:52 +02:00
|
|
|
EnvironmentOptions);
|
2003-06-08 19:43:00 +02:00
|
|
|
else
|
|
|
|
startpacket = pqBuildStartupPacket2(conn, &packetlen,
|
2005-10-15 04:49:52 +02:00
|
|
|
EnvironmentOptions);
|
2003-04-18 00:26:02 +02:00
|
|
|
if (!startpacket)
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
/*
|
|
|
|
* will not appendbuffer here, since it's likely to also
|
|
|
|
* run out of memory
|
|
|
|
*/
|
2003-04-18 00:26:02 +02:00
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
goto error_return;
|
|
|
|
}
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
|
|
|
* Send the startup packet.
|
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* Theoretically, this could block, but it really shouldn't
|
|
|
|
* since we only got here if the socket is write-ready.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
2003-04-18 00:26:02 +02:00
|
|
|
if (pqPacketSend(conn, 0, startpacket, packetlen) != STATUS_OK)
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not send startup packet: %s\n"),
|
|
|
|
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
|
2003-04-18 00:26:02 +02:00
|
|
|
free(startpacket);
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
free(startpacket);
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
conn->status = CONNECTION_AWAITING_RESPONSE;
|
1999-11-30 04:08:19 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2003-08-04 02:43:34 +02:00
|
|
|
* Handle SSL negotiation: wait for postmaster messages and
|
|
|
|
* respond as necessary.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
|
|
|
case CONNECTION_SSL_STARTUP:
|
|
|
|
{
|
|
|
|
#ifdef USE_SSL
|
|
|
|
PostgresPollingStatusType pollres;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* On first time through, get the postmaster's response to our
|
|
|
|
* SSL negotiation packet.
|
2003-06-08 19:43:00 +02:00
|
|
|
*/
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
if (!conn->ssl_in_use)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
2005-01-06 21:06:58 +01:00
|
|
|
/*
|
|
|
|
* We use pqReadData here since it has the logic to
|
2005-10-15 04:49:52 +02:00
|
|
|
* distinguish no-data-yet from connection closure. Since
|
|
|
|
* conn->ssl isn't set, a plain recv() will occur.
|
2005-01-06 21:06:58 +01:00
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
char SSLok;
|
2005-01-06 21:06:58 +01:00
|
|
|
int rdresult;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
2005-01-06 21:06:58 +01:00
|
|
|
rdresult = pqReadData(conn);
|
|
|
|
if (rdresult < 0)
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
2005-01-06 21:06:58 +01:00
|
|
|
/* errorMessage is already filled in */
|
2003-06-08 19:43:00 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
2005-01-06 21:06:58 +01:00
|
|
|
if (rdresult == 0)
|
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
/* caller failed to wait for data */
|
|
|
|
return PGRES_POLLING_READING;
|
2005-01-06 21:06:58 +01:00
|
|
|
}
|
|
|
|
if (pqGetc(&SSLok, conn) < 0)
|
|
|
|
{
|
|
|
|
/* should not happen really */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
if (SSLok == 'S')
|
|
|
|
{
|
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
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.
2011-08-27 22:36:57 +02:00
|
|
|
/* mark byte consumed */
|
|
|
|
conn->inStart = conn->inCursor;
|
2008-11-03 15:18:57 +01:00
|
|
|
/* Set up global SSL state if required */
|
2010-05-26 23:39:27 +02:00
|
|
|
if (pqsecure_initialize(conn) != 0)
|
2003-06-08 19:43:00 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
else if (SSLok == 'N')
|
|
|
|
{
|
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
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.
2011-08-27 22:36:57 +02:00
|
|
|
/* mark byte consumed */
|
|
|
|
conn->inStart = conn->inCursor;
|
|
|
|
/* OK to do without SSL? */
|
2009-04-24 11:43:10 +02:00
|
|
|
if (conn->sslmode[0] == 'r' || /* "require" */
|
2009-06-11 16:49:15 +02:00
|
|
|
conn->sslmode[0] == 'v') /* "verify-ca" or
|
|
|
|
* "verify-full" */
|
2003-08-01 23:27:27 +02:00
|
|
|
{
|
|
|
|
/* Require SSL, but server does not want it */
|
2013-11-18 17:29:01 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
libpq_gettext("server does not support SSL, but SSL was required\n"));
|
2003-08-01 23:27:27 +02:00
|
|
|
goto error_return;
|
2003-06-08 19:43:00 +02:00
|
|
|
}
|
|
|
|
/* Otherwise, proceed with normal startup */
|
|
|
|
conn->allow_ssl_try = false;
|
|
|
|
conn->status = CONNECTION_MADE;
|
|
|
|
return PGRES_POLLING_WRITING;
|
|
|
|
}
|
|
|
|
else if (SSLok == 'E')
|
|
|
|
{
|
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
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.
2011-08-27 22:36:57 +02:00
|
|
|
/*
|
|
|
|
* Server failure of some sort, such as failure to
|
2014-05-06 18:12:18 +02:00
|
|
|
* fork a backend process. We need to process and
|
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
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.
2011-08-27 22:36:57 +02:00
|
|
|
* report the error message, which might be formatted
|
|
|
|
* according to either protocol 2 or protocol 3.
|
|
|
|
* Rather than duplicate the code for that, we flip
|
|
|
|
* into AWAITING_RESPONSE state and let the code there
|
|
|
|
* deal with it. Note we have *not* consumed the "E"
|
|
|
|
* byte here.
|
|
|
|
*/
|
|
|
|
conn->status = CONNECTION_AWAITING_RESPONSE;
|
2003-06-08 19:43:00 +02:00
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2003-06-08 19:43:00 +02:00
|
|
|
libpq_gettext("received invalid response to SSL negotiation: %c\n"),
|
|
|
|
SSLok);
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/*
|
|
|
|
* Begin or continue the SSL negotiation process.
|
|
|
|
*/
|
|
|
|
pollres = pqsecure_open_client(conn);
|
|
|
|
if (pollres == PGRES_POLLING_OK)
|
|
|
|
{
|
|
|
|
/* SSL handshake done, ready to send startup packet */
|
|
|
|
conn->status = CONNECTION_MADE;
|
|
|
|
return PGRES_POLLING_WRITING;
|
|
|
|
}
|
2006-11-21 17:28:00 +01:00
|
|
|
if (pollres == PGRES_POLLING_FAILED)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Failed ... if sslmode is "prefer" then do a non-SSL
|
|
|
|
* retry
|
|
|
|
*/
|
|
|
|
if (conn->sslmode[0] == 'p' /* "prefer" */
|
|
|
|
&& conn->allow_ssl_try /* redundant? */
|
|
|
|
&& !conn->wait_ssl_try) /* redundant? */
|
|
|
|
{
|
|
|
|
/* only retry once */
|
|
|
|
conn->allow_ssl_try = false;
|
|
|
|
/* Must drop the old connection */
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2006-11-21 17:28:00 +01:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
return pollres;
|
2003-08-04 02:43:34 +02:00
|
|
|
#else /* !USE_SSL */
|
2003-06-08 19:43:00 +02:00
|
|
|
/* can't get here */
|
|
|
|
goto error_return;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_SSL */
|
2003-06-08 19:43:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Handle authentication exchange: wait for postmaster messages
|
|
|
|
* and respond as necessary.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
|
|
|
case CONNECTION_AWAITING_RESPONSE:
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
char beresp;
|
2003-04-22 02:08:07 +02:00
|
|
|
int msgLength;
|
|
|
|
int avail;
|
2000-04-12 19:17:23 +02:00
|
|
|
AuthRequest areq;
|
2017-04-13 18:34:14 +02:00
|
|
|
int res;
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Scan the message from current point (note that if we find
|
|
|
|
* the message is incomplete, we will return without advancing
|
|
|
|
* inStart, and resume here next time).
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
|
|
|
conn->inCursor = conn->inStart;
|
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/* Read type byte */
|
2000-04-12 19:17:23 +02:00
|
|
|
if (pqGetc(&beresp, conn))
|
2000-01-14 06:33:15 +01:00
|
|
|
{
|
2002-08-27 17:02:50 +02:00
|
|
|
/* We'll come back when there is more data */
|
2000-01-14 06:33:15 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
|
|
|
* Validate message type: we expect only an authentication
|
|
|
|
* request or an error here. Anything else probably means
|
|
|
|
* it's not Postgres on the other end at all.
|
|
|
|
*/
|
|
|
|
if (!(beresp == 'R' || beresp == 'E'))
|
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2003-04-22 02:08:07 +02:00
|
|
|
libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"expected authentication request from "
|
|
|
|
"server, but received %c\n"),
|
2003-04-22 02:08:07 +02:00
|
|
|
beresp);
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Read message length word */
|
|
|
|
if (pqGetInt(&msgLength, 4, conn))
|
|
|
|
{
|
|
|
|
/* We'll come back when there is more data */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Set phony message length to disable checks below */
|
|
|
|
msgLength = 8;
|
2003-04-22 02:08:07 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to validate message length before using it.
|
2007-07-10 15:14:22 +02:00
|
|
|
* Authentication requests can't be very large, although GSS
|
2007-11-15 22:14:46 +01:00
|
|
|
* auth requests may not be that small. Errors can be a
|
|
|
|
* little larger, but not huge. If we see a large apparent
|
2005-10-15 04:49:52 +02:00
|
|
|
* length in an error, it means we're really talking to a
|
|
|
|
* pre-3.0-protocol server; cope.
|
2003-04-22 02:08:07 +02:00
|
|
|
*/
|
2007-07-10 15:14:22 +02:00
|
|
|
if (beresp == 'R' && (msgLength < 8 || msgLength > 2000))
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2003-04-22 02:08:07 +02:00
|
|
|
libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"expected authentication request from "
|
|
|
|
"server, but received %c\n"),
|
2003-04-22 02:08:07 +02:00
|
|
|
beresp);
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (beresp == 'E' && (msgLength < 8 || msgLength > 30000))
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2003-04-22 02:08:07 +02:00
|
|
|
/* Handle error from a pre-3.0 server */
|
2003-08-04 02:43:34 +02:00
|
|
|
conn->inCursor = conn->inStart + 1; /* reread data */
|
2008-10-27 10:42:31 +01:00
|
|
|
if (pqGets_append(&conn->errorMessage, conn))
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2002-08-27 18:21:51 +02:00
|
|
|
/* We'll come back when there is more data */
|
2000-04-12 19:17:23 +02:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
/* OK, we read the message; mark data consumed */
|
|
|
|
conn->inStart = conn->inCursor;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* The postmaster typically won't end its message with a
|
|
|
|
* newline, so add one to conform to libpq conventions.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
|
|
|
appendPQExpBufferChar(&conn->errorMessage, '\n');
|
2003-06-08 19:43:00 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we tried to open the connection in 3.0 protocol,
|
|
|
|
* fall back to 2.0 protocol.
|
|
|
|
*/
|
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
conn->pversion = PG_PROTOCOL(2, 0);
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Must drop the old connection */
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
|
|
|
* Can't process if message body isn't all here yet.
|
2003-06-08 19:43:00 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* (In protocol 2.0 case, we are assuming messages carry at
|
|
|
|
* least 4 bytes of data.)
|
2003-04-22 02:08:07 +02:00
|
|
|
*/
|
|
|
|
msgLength -= 4;
|
|
|
|
avail = conn->inEnd - conn->inCursor;
|
|
|
|
if (avail < msgLength)
|
2000-04-12 19:17:23 +02:00
|
|
|
{
|
2003-04-22 02:08:07 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Before returning, try to enlarge the input buffer if
|
|
|
|
* needed to hold the whole message; see notes in
|
2003-06-08 19:43:00 +02:00
|
|
|
* pqParseInput3.
|
2003-04-22 02:08:07 +02:00
|
|
|
*/
|
2008-05-30 00:02:44 +02:00
|
|
|
if (pqCheckInBufferSpace(conn->inCursor + (size_t) msgLength,
|
|
|
|
conn))
|
2003-04-22 02:08:07 +02:00
|
|
|
goto error_return;
|
|
|
|
/* We'll come back when there is more data */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle errors. */
|
|
|
|
if (beresp == 'E')
|
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
|
2003-04-22 02:08:07 +02:00
|
|
|
{
|
2003-06-08 19:43:00 +02:00
|
|
|
if (pqGetErrorNotice3(conn, true))
|
|
|
|
{
|
|
|
|
/* We'll come back when there is more data */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2008-10-27 10:42:31 +01:00
|
|
|
if (pqGets_append(&conn->errorMessage, conn))
|
2003-06-08 19:43:00 +02:00
|
|
|
{
|
|
|
|
/* We'll come back when there is more data */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
2003-04-22 02:08:07 +02:00
|
|
|
}
|
|
|
|
/* OK, we read the message; mark data consumed */
|
|
|
|
conn->inStart = conn->inCursor;
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
|
|
|
|
#ifdef USE_SSL
|
2003-08-04 02:43:34 +02:00
|
|
|
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
/*
|
2003-08-01 23:27:27 +02:00
|
|
|
* if sslmode is "allow" and we haven't tried an SSL
|
2005-10-15 04:49:52 +02:00
|
|
|
* connection already, then retry with an SSL connection
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
*/
|
2003-08-01 23:27:27 +02:00
|
|
|
if (conn->sslmode[0] == 'a' /* "allow" */
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
&& !conn->ssl_in_use
|
2003-08-01 23:27:27 +02:00
|
|
|
&& conn->allow_ssl_try
|
|
|
|
&& conn->wait_ssl_try)
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
{
|
2003-08-01 23:27:27 +02:00
|
|
|
/* only retry once */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->wait_ssl_try = false;
|
|
|
|
/* Must drop the old connection */
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* if sslmode is "prefer" and we're in an SSL connection,
|
|
|
|
* then do a non-SSL retry
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
*/
|
2003-08-01 23:27:27 +02:00
|
|
|
if (conn->sslmode[0] == 'p' /* "prefer" */
|
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
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.
2011-08-27 22:36:57 +02:00
|
|
|
&& conn->allow_ssl_try
|
2003-08-04 02:43:34 +02:00
|
|
|
&& !conn->wait_ssl_try) /* redundant? */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
{
|
2003-08-01 23:27:27 +02:00
|
|
|
/* only retry once */
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->allow_ssl_try = false;
|
|
|
|
/* Must drop the old connection */
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
2003-07-26 15:50:02 +02:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2003-04-22 02:08:07 +02:00
|
|
|
/* It is an authentication request. */
|
2010-11-27 08:11:45 +01:00
|
|
|
conn->auth_req_received = true;
|
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/* Get the type of request. */
|
|
|
|
if (pqGetInt((int *) &areq, 4, conn))
|
1999-11-30 04:08:19 +01:00
|
|
|
{
|
|
|
|
/* We'll come back when there are more data */
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
2017-04-13 18:34:14 +02:00
|
|
|
msgLength -= 4;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-07-10 15:14:22 +02:00
|
|
|
/*
|
2017-04-13 18:34:14 +02:00
|
|
|
* Ensure the password salt is in the input buffer, if it's an
|
|
|
|
* MD5 request. All the other authentication methods that
|
|
|
|
* contain extra data in the authentication request are only
|
|
|
|
* supported in protocol version 3, in which case we already
|
|
|
|
* read the whole message above.
|
2007-07-10 15:14:22 +02:00
|
|
|
*/
|
2017-04-13 18:34:14 +02:00
|
|
|
if (areq == AUTH_REQ_MD5 && PG_PROTOCOL_MAJOR(conn->pversion) < 3)
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
{
|
2017-04-13 18:34:14 +02:00
|
|
|
msgLength += 4;
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
|
2017-04-13 18:34:14 +02:00
|
|
|
avail = conn->inEnd - conn->inCursor;
|
|
|
|
if (avail < 4)
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
{
|
2017-04-13 18:34:14 +02:00
|
|
|
/*
|
|
|
|
* Before returning, try to enlarge the input buffer
|
|
|
|
* if needed to hold the whole message; see notes in
|
|
|
|
* pqParseInput3.
|
|
|
|
*/
|
|
|
|
if (pqCheckInBufferSpace(conn->inCursor + (size_t) 4,
|
|
|
|
conn))
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
goto error_return;
|
2017-04-13 18:34:14 +02:00
|
|
|
/* We'll come back when there is more data */
|
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
}
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
/*
|
2017-04-13 18:34:14 +02:00
|
|
|
* Process the rest of the authentication request message, and
|
|
|
|
* respond to it if necessary.
|
|
|
|
*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Note that conn->pghost must be non-NULL if we are going to
|
|
|
|
* avoid the Kerberos code doing a hostname look-up.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
2017-04-13 18:34:14 +02:00
|
|
|
res = pg_fe_sendauth(areq, msgLength, conn);
|
|
|
|
conn->errorMessage.len = strlen(conn->errorMessage.data);
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2017-04-13 18:34:14 +02:00
|
|
|
/* OK, we have processed the message; mark data consumed */
|
|
|
|
conn->inStart = conn->inCursor;
|
|
|
|
|
|
|
|
if (res != STATUS_OK)
|
2000-04-12 19:17:23 +02:00
|
|
|
goto error_return;
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2005-10-17 18:24:20 +02:00
|
|
|
* Just make sure that any data sent by pg_fe_sendauth is
|
|
|
|
* flushed out. Although this theoretically could block, it
|
|
|
|
* really shouldn't since we don't send large auth responses.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
|
|
|
if (pqFlush(conn))
|
|
|
|
goto error_return;
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
if (areq == AUTH_REQ_OK)
|
|
|
|
{
|
|
|
|
/* We are done with authentication exchange */
|
|
|
|
conn->status = CONNECTION_AUTH_OK;
|
|
|
|
|
|
|
|
/*
|
2012-04-05 00:27:56 +02:00
|
|
|
* Set asyncStatus so that PQgetResult will think that
|
2000-04-12 19:17:23 +02:00
|
|
|
* what comes back next is the result of a query. See
|
|
|
|
* below.
|
|
|
|
*/
|
|
|
|
conn->asyncStatus = PGASYNC_BUSY;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/* Look to see if we have more data yet. */
|
|
|
|
goto keep_going;
|
|
|
|
}
|
1999-08-31 03:37:37 +02:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
case CONNECTION_AUTH_OK:
|
|
|
|
{
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2000-04-12 19:17:23 +02:00
|
|
|
* Now we expect to hear from the backend. A ReadyForQuery
|
2005-10-15 04:49:52 +02:00
|
|
|
* message indicates that startup is successful, but we might
|
|
|
|
* also get an Error message indicating failure. (Notice
|
|
|
|
* messages indicating nonfatal warnings are also allowed by
|
|
|
|
* the protocol, as are ParameterStatus and BackendKeyData
|
|
|
|
* messages.) Easiest way to handle this is to let
|
|
|
|
* PQgetResult() read the messages. We just have to fake it
|
|
|
|
* out about the state of the connection, by setting
|
|
|
|
* asyncStatus = PGASYNC_BUSY (done above).
|
2000-01-14 06:33:15 +01:00
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
if (PQisBusy(conn))
|
|
|
|
return PGRES_POLLING_READING;
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
res = PQgetResult(conn);
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
|
|
|
* NULL return indicating we have gone to IDLE state is
|
|
|
|
* expected
|
|
|
|
*/
|
|
|
|
if (res)
|
|
|
|
{
|
|
|
|
if (res->resultStatus != PGRES_FATAL_ERROR)
|
2013-11-18 17:29:01 +01:00
|
|
|
appendPQExpBufferStr(&conn->errorMessage,
|
|
|
|
libpq_gettext("unexpected message from server during startup\n"));
|
2009-12-02 05:38:35 +01:00
|
|
|
else if (conn->send_appname &&
|
|
|
|
(conn->appname || conn->fbappname))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If we tried to send application_name, check to see
|
2010-02-17 05:19:41 +01:00
|
|
|
* if the error is about that --- pre-9.0 servers will
|
2014-05-06 18:12:18 +02:00
|
|
|
* reject it at this stage of the process. If so,
|
2009-12-02 05:38:35 +01:00
|
|
|
* close the connection and retry without sending
|
|
|
|
* application_name. We could possibly get a false
|
|
|
|
* SQLSTATE match here and retry uselessly, but there
|
|
|
|
* seems no great harm in that; we'll just get the
|
|
|
|
* same error again if it's unrelated.
|
|
|
|
*/
|
|
|
|
const char *sqlstate;
|
|
|
|
|
|
|
|
sqlstate = PQresultErrorField(res, PG_DIAG_SQLSTATE);
|
|
|
|
if (sqlstate &&
|
|
|
|
strcmp(sqlstate, ERRCODE_APPNAME_UNKNOWN) == 0)
|
|
|
|
{
|
|
|
|
PQclear(res);
|
|
|
|
conn->send_appname = false;
|
|
|
|
/* Must drop the old connection */
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
2009-12-02 05:38:35 +01:00
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
}
|
2000-04-12 19:17:23 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* if the resultStatus is FATAL, then conn->errorMessage
|
|
|
|
* already has a copy of the error; needn't copy it back.
|
|
|
|
* But add a newline if it's not there already, since
|
|
|
|
* postmaster error messages may not have one.
|
2000-04-12 19:17:23 +02:00
|
|
|
*/
|
|
|
|
if (conn->errorMessage.len <= 0 ||
|
|
|
|
conn->errorMessage.data[conn->errorMessage.len - 1] != '\n')
|
|
|
|
appendPQExpBufferChar(&conn->errorMessage, '\n');
|
|
|
|
PQclear(res);
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
/* Fire up post-connection housekeeping if needed */
|
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) < 3)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_SETENV;
|
2011-02-19 07:54:58 +01:00
|
|
|
conn->setenv_state = SETENV_STATE_CLIENT_ENCODING_SEND;
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->next_eo = EnvironmentOptions;
|
|
|
|
return PGRES_POLLING_WRITING;
|
|
|
|
}
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
/*
|
|
|
|
* If a read-write connection is required, see if we have one.
|
|
|
|
*/
|
|
|
|
if (conn->target_session_attrs != NULL &&
|
|
|
|
strcmp(conn->target_session_attrs, "read-write") == 0)
|
|
|
|
{
|
2016-12-05 20:09:54 +01:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* We are yet to make a connection. Save all existing
|
|
|
|
* error messages until we make a successful connection
|
|
|
|
* state. This is important because PQsendQuery is going
|
|
|
|
* to reset conn->errorMessage and we will lose error
|
|
|
|
* messages related to previous hosts we have tried to
|
|
|
|
* connect and failed.
|
2016-12-05 20:09:54 +01:00
|
|
|
*/
|
|
|
|
if (!saveErrorMessage(conn, &savedMessage))
|
|
|
|
goto error_return;
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
if (!PQsendQuery(conn,
|
2017-05-19 21:48:10 +02:00
|
|
|
"SHOW transaction_read_only"))
|
2016-12-05 20:09:54 +01:00
|
|
|
{
|
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
goto error_return;
|
2016-12-05 20:09:54 +01:00
|
|
|
}
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_CHECK_WRITABLE;
|
2016-12-05 20:09:54 +01:00
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We can release the address lists now. */
|
|
|
|
release_all_addrinfo(conn);
|
|
|
|
|
|
|
|
/* We are open for business! */
|
2003-04-25 21:45:10 +02:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
return PGRES_POLLING_OK;
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
2003-06-08 19:43:00 +02:00
|
|
|
case CONNECTION_SETENV:
|
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
/*
|
|
|
|
* Do post-connection housekeeping (only needed in protocol 2.0).
|
|
|
|
*
|
|
|
|
* We pretend that the connection is OK for the duration of these
|
|
|
|
* queries.
|
|
|
|
*/
|
|
|
|
conn->status = CONNECTION_OK;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
switch (pqSetenvPoll(conn))
|
|
|
|
{
|
|
|
|
case PGRES_POLLING_OK: /* Success */
|
|
|
|
break;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
case PGRES_POLLING_READING: /* Still going */
|
2009-12-02 05:38:35 +01:00
|
|
|
conn->status = CONNECTION_SETENV;
|
|
|
|
return PGRES_POLLING_READING;
|
2003-06-08 19:43:00 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
case PGRES_POLLING_WRITING: /* Still going */
|
2009-12-02 05:38:35 +01:00
|
|
|
conn->status = CONNECTION_SETENV;
|
|
|
|
return PGRES_POLLING_WRITING;
|
2009-11-29 00:38:08 +01:00
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
default:
|
|
|
|
goto error_return;
|
2009-11-29 00:38:08 +01:00
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
/*
|
2017-02-15 03:06:13 +01:00
|
|
|
* If a read-write connection is requested check for same.
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
*/
|
|
|
|
if (conn->target_session_attrs != NULL &&
|
|
|
|
strcmp(conn->target_session_attrs, "read-write") == 0)
|
|
|
|
{
|
2016-12-05 20:09:54 +01:00
|
|
|
if (!saveErrorMessage(conn, &savedMessage))
|
|
|
|
goto error_return;
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
if (!PQsendQuery(conn,
|
2017-05-19 21:48:10 +02:00
|
|
|
"SHOW transaction_read_only"))
|
2016-12-05 20:09:54 +01:00
|
|
|
{
|
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
goto error_return;
|
2016-12-05 20:09:54 +01:00
|
|
|
}
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_CHECK_WRITABLE;
|
2016-12-05 20:09:54 +01:00
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We can release the address lists now. */
|
|
|
|
release_all_addrinfo(conn);
|
|
|
|
|
2009-12-02 05:38:35 +01:00
|
|
|
/* We are open for business! */
|
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
return PGRES_POLLING_OK;
|
|
|
|
|
2017-02-15 17:03:30 +01:00
|
|
|
case CONNECTION_CONSUME:
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
if (!PQconsumeInput(conn))
|
|
|
|
goto error_return;
|
|
|
|
|
|
|
|
if (PQisBusy(conn))
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_CONSUME;
|
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Call PQgetResult() again to consume NULL result.
|
|
|
|
*/
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (res != NULL)
|
|
|
|
{
|
|
|
|
PQclear(res);
|
|
|
|
conn->status = CONNECTION_CONSUME;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We are open for business! */
|
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
return PGRES_POLLING_OK;
|
|
|
|
}
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
case CONNECTION_CHECK_WRITABLE:
|
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
const char *displayed_host;
|
|
|
|
const char *displayed_port;
|
|
|
|
|
2016-12-05 20:09:54 +01:00
|
|
|
if (!saveErrorMessage(conn, &savedMessage))
|
|
|
|
goto error_return;
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
if (!PQconsumeInput(conn))
|
2016-12-05 20:09:54 +01:00
|
|
|
{
|
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
goto error_return;
|
2016-12-05 20:09:54 +01:00
|
|
|
}
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
|
|
|
|
if (PQisBusy(conn))
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_CHECK_WRITABLE;
|
2016-12-05 20:09:54 +01:00
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
return PGRES_POLLING_READING;
|
|
|
|
}
|
|
|
|
|
|
|
|
res = PQgetResult(conn);
|
|
|
|
if (res && (PQresultStatus(res) == PGRES_TUPLES_OK) &&
|
|
|
|
PQntuples(res) == 1)
|
|
|
|
{
|
|
|
|
char *val;
|
|
|
|
|
|
|
|
val = PQgetvalue(res, 0, 0);
|
|
|
|
if (strncmp(val, "on", 2) == 0)
|
|
|
|
{
|
2017-07-10 11:28:57 +02:00
|
|
|
const char *displayed_host;
|
|
|
|
const char *displayed_port;
|
|
|
|
|
|
|
|
if (conn->connhost[conn->whichhost].type == CHT_HOST_ADDRESS)
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].hostaddr;
|
|
|
|
else
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].host;
|
|
|
|
displayed_port = conn->connhost[conn->whichhost].port;
|
|
|
|
if (displayed_port == NULL || displayed_port[0] == '\0')
|
|
|
|
displayed_port = DEF_PGPORT_STR;
|
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
PQclear(res);
|
2016-12-05 20:09:54 +01:00
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
|
|
|
|
/* Not writable; close connection. */
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("could not make a writable "
|
|
|
|
"connection to server "
|
|
|
|
"\"%s:%s\"\n"),
|
2017-07-10 11:28:57 +02:00
|
|
|
displayed_host, displayed_port);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
sendTerminateConn(conn);
|
|
|
|
pqDropConnection(conn, true);
|
|
|
|
|
|
|
|
/* Skip any remaining addresses for this host. */
|
|
|
|
conn->addr_cur = NULL;
|
|
|
|
if (conn->whichhost + 1 < conn->nconnhost)
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No more addresses to try. So we fail. */
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
PQclear(res);
|
2016-12-05 20:09:54 +01:00
|
|
|
termPQExpBuffer(&savedMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
|
|
|
|
/* We can release the address lists now. */
|
|
|
|
release_all_addrinfo(conn);
|
|
|
|
|
2017-02-15 17:03:30 +01:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Finish reading any remaining messages before being
|
|
|
|
* considered as ready.
|
2017-02-15 17:03:30 +01:00
|
|
|
*/
|
|
|
|
conn->status = CONNECTION_CONSUME;
|
|
|
|
goto keep_going;
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-05-19 21:48:10 +02:00
|
|
|
* Something went wrong with "SHOW transaction_read_only". We
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
* should try next addresses.
|
|
|
|
*/
|
|
|
|
if (res)
|
|
|
|
PQclear(res);
|
2016-12-05 20:09:54 +01:00
|
|
|
restoreErrorMessage(conn, &savedMessage);
|
2017-07-10 11:28:57 +02:00
|
|
|
|
|
|
|
if (conn->connhost[conn->whichhost].type == CHT_HOST_ADDRESS)
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].hostaddr;
|
|
|
|
else
|
|
|
|
displayed_host = conn->connhost[conn->whichhost].host;
|
|
|
|
displayed_port = conn->connhost[conn->whichhost].port;
|
|
|
|
if (displayed_port == NULL || displayed_port[0] == '\0')
|
|
|
|
displayed_port = DEF_PGPORT_STR;
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("test \"SHOW transaction_read_only\" failed "
|
|
|
|
"on server \"%s:%s\"\n"),
|
2017-07-10 11:28:57 +02:00
|
|
|
displayed_host, displayed_port);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
conn->status = CONNECTION_OK;
|
|
|
|
sendTerminateConn(conn);
|
|
|
|
pqDropConnection(conn, true);
|
|
|
|
|
|
|
|
if (conn->addr_cur->ai_next != NULL ||
|
|
|
|
conn->whichhost + 1 < conn->nconnhost)
|
|
|
|
{
|
|
|
|
conn->addr_cur = conn->addr_cur->ai_next;
|
|
|
|
conn->status = CONNECTION_NEEDED;
|
|
|
|
goto keep_going;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No more addresses to try. So we fail. */
|
|
|
|
goto error_return;
|
|
|
|
}
|
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
default:
|
2008-10-27 10:42:31 +01:00
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
2009-11-29 00:38:08 +01:00
|
|
|
libpq_gettext("invalid connection state %d, "
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"probably indicative of memory corruption\n"),
|
2001-07-15 15:45:04 +02:00
|
|
|
conn->status);
|
1999-11-30 04:08:19 +01:00
|
|
|
goto error_return;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
1998-01-26 02:42:53 +01:00
|
|
|
|
1999-11-30 04:08:19 +01:00
|
|
|
/* Unreachable */
|
|
|
|
|
|
|
|
error_return:
|
2001-03-22 07:16:21 +01:00
|
|
|
|
2017-01-24 23:06:21 +01:00
|
|
|
pgpassfileWarning(conn);
|
2010-07-06 21:19:02 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We used to close the socket at this point, but that makes it awkward
|
|
|
|
* for those above us if they wish to remove this socket from their own
|
|
|
|
* records (an fd_set for example). We'll just have this socket closed
|
|
|
|
* when PQfinish is called (which is compulsory even after an error, since
|
|
|
|
* the connection structure must be freed).
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->status = CONNECTION_BAD;
|
1999-11-30 04:08:19 +01:00
|
|
|
return PGRES_POLLING_FAILED;
|
|
|
|
}
|
1998-05-07 01:51:16 +02:00
|
|
|
|
|
|
|
|
2010-11-25 19:09:38 +01:00
|
|
|
/*
|
|
|
|
* internal_ping
|
2010-11-27 07:30:34 +01:00
|
|
|
* Determine if a server is running and if we can connect to it.
|
|
|
|
*
|
|
|
|
* The argument is a connection that's been started, but not completed.
|
2010-11-25 19:09:38 +01:00
|
|
|
*/
|
2011-03-07 02:04:29 +01:00
|
|
|
static PGPing
|
2010-11-25 19:09:38 +01:00
|
|
|
internal_ping(PGconn *conn)
|
|
|
|
{
|
2010-11-27 07:30:34 +01:00
|
|
|
/* Say "no attempt" if we never got to PQconnectPoll */
|
|
|
|
if (!conn || !conn->options_valid)
|
|
|
|
return PQPING_NO_ATTEMPT;
|
|
|
|
|
|
|
|
/* Attempt to complete the connection */
|
|
|
|
if (conn->status != CONNECTION_BAD)
|
2010-11-25 19:09:38 +01:00
|
|
|
(void) connectDBComplete(conn);
|
|
|
|
|
2010-11-27 07:30:34 +01:00
|
|
|
/* Definitely OK if we succeeded */
|
|
|
|
if (conn->status != CONNECTION_BAD)
|
|
|
|
return PQPING_OK;
|
|
|
|
|
|
|
|
/*
|
2010-11-27 08:11:45 +01:00
|
|
|
* Here begins the interesting part of "ping": determine the cause of the
|
2010-11-27 07:30:34 +01:00
|
|
|
* failure in sufficient detail to decide what to return. We do not want
|
|
|
|
* to report that the server is not up just because we didn't have a valid
|
2010-11-27 08:11:45 +01:00
|
|
|
* password, for example. In fact, any sort of authentication request
|
2011-04-10 17:42:00 +02:00
|
|
|
* implies the server is up. (We need this check since the libpq side of
|
|
|
|
* things might have pulled the plug on the connection before getting an
|
|
|
|
* error as such from the postmaster.)
|
2010-11-27 08:11:45 +01:00
|
|
|
*/
|
|
|
|
if (conn->auth_req_received)
|
|
|
|
return PQPING_OK;
|
|
|
|
|
|
|
|
/*
|
2010-11-27 07:30:34 +01:00
|
|
|
* If we failed to get any ERROR response from the postmaster, report
|
2014-05-06 18:12:18 +02:00
|
|
|
* PQPING_NO_RESPONSE. This result could be somewhat misleading for a
|
2010-11-27 07:30:34 +01:00
|
|
|
* pre-7.4 server, since it won't send back a SQLSTATE, but those are long
|
2014-05-06 18:12:18 +02:00
|
|
|
* out of support. Another corner case where the server could return a
|
2010-11-27 07:30:34 +01:00
|
|
|
* failure without a SQLSTATE is fork failure, but NO_RESPONSE isn't
|
|
|
|
* totally unreasonable for that anyway. We expect that every other
|
|
|
|
* failure case in a modern server will produce a report with a SQLSTATE.
|
|
|
|
*
|
|
|
|
* NOTE: whenever we get around to making libpq generate SQLSTATEs for
|
|
|
|
* client-side errors, we should either not store those into
|
|
|
|
* last_sqlstate, or add an extra flag so we can tell client-side errors
|
|
|
|
* apart from server-side ones.
|
|
|
|
*/
|
|
|
|
if (strlen(conn->last_sqlstate) != 5)
|
|
|
|
return PQPING_NO_RESPONSE;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Report PQPING_REJECT if server says it's not accepting connections. (We
|
|
|
|
* distinguish this case mainly for the convenience of pg_ctl.)
|
2010-11-27 07:30:34 +01:00
|
|
|
*/
|
|
|
|
if (strcmp(conn->last_sqlstate, ERRCODE_CANNOT_CONNECT_NOW) == 0)
|
|
|
|
return PQPING_REJECT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Any other SQLSTATE can be taken to indicate that the server is up.
|
|
|
|
* Presumably it didn't like our username, password, or database name; or
|
|
|
|
* perhaps it had some transient failure, but that should not be taken as
|
|
|
|
* meaning "it's down".
|
|
|
|
*/
|
|
|
|
return PQPING_OK;
|
2010-11-25 19:09:38 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/*
|
|
|
|
* makeEmptyPGconn
|
1998-09-01 06:40:42 +02:00
|
|
|
* - create a PGconn data structure with (as yet) no interesting data
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
|
|
|
static PGconn *
|
|
|
|
makeEmptyPGconn(void)
|
|
|
|
{
|
2003-08-01 23:27:27 +02:00
|
|
|
PGconn *conn;
|
1998-09-01 06:40:42 +02:00
|
|
|
|
2003-07-27 05:32:26 +02:00
|
|
|
#ifdef WIN32
|
2014-05-06 18:12:18 +02:00
|
|
|
|
2005-05-05 18:40:42 +02:00
|
|
|
/*
|
2007-03-08 20:27:28 +01:00
|
|
|
* Make sure socket support is up and running.
|
2005-05-05 18:40:42 +02:00
|
|
|
*/
|
2003-08-04 02:43:34 +02:00
|
|
|
WSADATA wsaData;
|
2003-07-27 05:32:26 +02:00
|
|
|
|
|
|
|
if (WSAStartup(MAKEWORD(1, 1), &wsaData))
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
2003-07-27 05:32:26 +02:00
|
|
|
WSASetLastError(0);
|
|
|
|
#endif
|
|
|
|
|
2003-08-01 23:27:27 +02:00
|
|
|
conn = (PGconn *) malloc(sizeof(PGconn));
|
|
|
|
if (conn == NULL)
|
2007-03-08 20:27:28 +01:00
|
|
|
{
|
|
|
|
#ifdef WIN32
|
|
|
|
WSACleanup();
|
|
|
|
#endif
|
2003-08-01 23:27:27 +02:00
|
|
|
return conn;
|
2007-03-08 20:27:28 +01:00
|
|
|
}
|
2003-08-01 23:27:27 +02:00
|
|
|
|
2000-01-14 06:33:15 +01:00
|
|
|
/* Zero all pointers and booleans */
|
2004-01-07 19:56:30 +01:00
|
|
|
MemSet(conn, 0, sizeof(PGconn));
|
1998-05-07 01:51:16 +02:00
|
|
|
|
2012-08-02 19:10:30 +02:00
|
|
|
/* install default notice hooks */
|
2003-06-21 23:51:35 +02:00
|
|
|
conn->noticeHooks.noticeRec = defaultNoticeReceiver;
|
|
|
|
conn->noticeHooks.noticeProc = defaultNoticeProcessor;
|
2012-04-05 00:27:56 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
conn->asyncStatus = PGASYNC_IDLE;
|
2003-06-21 23:51:35 +02:00
|
|
|
conn->xactStatus = PQTRANS_IDLE;
|
2006-02-13 23:33:57 +01:00
|
|
|
conn->options_valid = false;
|
|
|
|
conn->nonblocking = false;
|
2003-06-08 19:43:00 +02:00
|
|
|
conn->setenv_state = SETENV_STATE_IDLE;
|
|
|
|
conn->client_encoding = PG_SQL_ASCII;
|
Modify libpq's string-escaping routines to be aware of encoding considerations
and standard_conforming_strings. The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection. An actual fix requires changing the
client-side code. While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.
Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn. The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables. This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.
Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(. It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
|
|
|
conn->std_strings = false; /* unless server says differently */
|
2003-06-21 23:51:35 +02:00
|
|
|
conn->verbosity = PQERRORS_DEFAULT;
|
2015-09-05 17:58:20 +02:00
|
|
|
conn->show_context = PQSHOW_CONTEXT_ERRORS;
|
2014-04-17 01:46:51 +02:00
|
|
|
conn->sock = PGINVALID_SOCKET;
|
2010-11-27 08:11:45 +01:00
|
|
|
conn->auth_req_received = false;
|
2007-12-09 20:01:40 +01:00
|
|
|
conn->password_needed = false;
|
2017-01-24 23:06:21 +01:00
|
|
|
conn->pgpassfile_used = false;
|
2000-01-14 06:33:15 +01:00
|
|
|
#ifdef USE_SSL
|
2003-08-01 23:27:27 +02:00
|
|
|
conn->allow_ssl_try = true;
|
|
|
|
conn->wait_ssl_try = false;
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
conn->ssl_in_use = false;
|
2000-01-14 06:33:15 +01:00
|
|
|
#endif
|
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We try to send at least 8K at a time, which is the usual size of pipe
|
|
|
|
* buffers on Unix systems. That way, when we are sending a large amount
|
|
|
|
* of data, we avoid incurring extra kernel context swaps for partial
|
|
|
|
* bufferloads. The output buffer is initially made 16K in size, and we
|
|
|
|
* try to dump it after accumulating 8K.
|
1999-08-31 03:37:37 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* With the same goal of minimizing context swaps, the input buffer will
|
|
|
|
* be enlarged anytime it has less than 8K free, so we initially allocate
|
2005-10-15 04:49:52 +02:00
|
|
|
* twice that.
|
1999-08-31 03:37:37 +02:00
|
|
|
*/
|
|
|
|
conn->inBufSize = 16 * 1024;
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->inBuffer = (char *) malloc(conn->inBufSize);
|
2003-04-19 02:02:30 +02:00
|
|
|
conn->outBufSize = 16 * 1024;
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->outBuffer = (char *) malloc(conn->outBufSize);
|
2012-04-05 00:27:56 +02:00
|
|
|
conn->rowBufLen = 32;
|
|
|
|
conn->rowBuf = (PGdataValue *) malloc(conn->rowBufLen * sizeof(PGdataValue));
|
1999-08-31 03:37:37 +02:00
|
|
|
initPQExpBuffer(&conn->errorMessage);
|
|
|
|
initPQExpBuffer(&conn->workBuffer);
|
2003-06-08 19:43:00 +02:00
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
if (conn->inBuffer == NULL ||
|
|
|
|
conn->outBuffer == NULL ||
|
2012-04-05 00:27:56 +02:00
|
|
|
conn->rowBuf == NULL ||
|
2008-11-26 01:26:23 +01:00
|
|
|
PQExpBufferBroken(&conn->errorMessage) ||
|
|
|
|
PQExpBufferBroken(&conn->workBuffer))
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
2000-01-14 06:33:15 +01:00
|
|
|
/* out of memory already :-( */
|
1998-05-07 01:51:16 +02:00
|
|
|
freePGconn(conn);
|
|
|
|
conn = NULL;
|
|
|
|
}
|
2003-06-08 19:43:00 +02:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* freePGconn
|
2008-01-29 03:06:30 +01:00
|
|
|
* - free an idle (closed) PGconn data structure
|
2005-07-13 17:25:55 +02:00
|
|
|
*
|
2008-01-29 03:06:30 +01:00
|
|
|
* NOTE: this should not overlap any functionality with closePGconn().
|
|
|
|
* Clearing/resetting of transient state belongs there; what we do here is
|
|
|
|
* release data that is to be held for the life of the PGconn structure.
|
|
|
|
* If a value ought to be cleared/freed during PQreset(), do it there not here.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static void
|
1997-09-08 23:56:23 +02:00
|
|
|
freePGconn(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2008-09-17 06:31:08 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
/* let any event procs clean up their state data */
|
|
|
|
for (i = 0; i < conn->nEvents; i++)
|
|
|
|
{
|
|
|
|
PGEventConnDestroy evt;
|
|
|
|
|
|
|
|
evt.conn = conn;
|
|
|
|
(void) conn->events[i].proc(PGEVT_CONNDESTROY, &evt,
|
|
|
|
conn->events[i].passThrough);
|
|
|
|
free(conn->events[i].name);
|
|
|
|
}
|
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/* clean up pg_conn_host structures */
|
|
|
|
if (conn->connhost != NULL)
|
|
|
|
{
|
|
|
|
for (i = 0; i < conn->nconnhost; ++i)
|
|
|
|
{
|
|
|
|
if (conn->connhost[i].host != NULL)
|
|
|
|
free(conn->connhost[i].host);
|
2017-07-10 11:28:57 +02:00
|
|
|
if (conn->connhost[i].hostaddr != NULL)
|
|
|
|
free(conn->connhost[i].hostaddr);
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->connhost[i].port != NULL)
|
|
|
|
free(conn->connhost[i].port);
|
|
|
|
if (conn->connhost[i].password != NULL)
|
|
|
|
free(conn->connhost[i].password);
|
|
|
|
}
|
|
|
|
free(conn->connhost);
|
|
|
|
}
|
|
|
|
|
2012-03-07 22:35:03 +01:00
|
|
|
if (conn->client_encoding_initial)
|
|
|
|
free(conn->client_encoding_initial);
|
2008-09-17 06:31:08 +02:00
|
|
|
if (conn->events)
|
|
|
|
free(conn->events);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn->pghost)
|
|
|
|
free(conn->pghost);
|
1999-11-30 04:08:19 +01:00
|
|
|
if (conn->pghostaddr)
|
|
|
|
free(conn->pghostaddr);
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->pgport)
|
|
|
|
free(conn->pgport);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn->pgtty)
|
|
|
|
free(conn->pgtty);
|
2003-06-08 19:43:00 +02:00
|
|
|
if (conn->connect_timeout)
|
|
|
|
free(conn->connect_timeout);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn->pgoptions)
|
|
|
|
free(conn->pgoptions);
|
2009-11-29 00:38:08 +01:00
|
|
|
if (conn->appname)
|
|
|
|
free(conn->appname);
|
|
|
|
if (conn->fbappname)
|
|
|
|
free(conn->fbappname);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn->dbName)
|
|
|
|
free(conn->dbName);
|
2010-01-15 10:19:10 +01:00
|
|
|
if (conn->replication)
|
|
|
|
free(conn->replication);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (conn->pguser)
|
|
|
|
free(conn->pguser);
|
1998-04-21 06:00:06 +02:00
|
|
|
if (conn->pgpass)
|
|
|
|
free(conn->pgpass);
|
2017-01-24 23:06:21 +01:00
|
|
|
if (conn->pgpassfile)
|
|
|
|
free(conn->pgpassfile);
|
Add TCP keepalive support to libpq.
This adds four additional connection parameters to libpq: keepalives,
keepalives_idle, keepalives_count, and keepalives_interval.
keepalives default to on, per discussion, but can be turned off by
specifying keepalives=0. The remaining parameters, where supported,
can be used to adjust how often keepalives are sent and how many
can be lost before the connection is broken.
The immediate motivation for this patch is to make sure that
walreceiver will eventually notice if the master reboots without
closing the connection cleanly, but it should be helpful in other
cases as well.
Tollef Fog Heen, Fujii Masao, and me.
2010-06-23 23:54:13 +02:00
|
|
|
if (conn->keepalives)
|
|
|
|
free(conn->keepalives);
|
|
|
|
if (conn->keepalives_idle)
|
|
|
|
free(conn->keepalives_idle);
|
|
|
|
if (conn->keepalives_interval)
|
|
|
|
free(conn->keepalives_interval);
|
|
|
|
if (conn->keepalives_count)
|
|
|
|
free(conn->keepalives_count);
|
2017-12-19 00:05:24 +01:00
|
|
|
if (conn->scram_channel_binding)
|
|
|
|
free(conn->scram_channel_binding);
|
2003-08-01 23:27:27 +02:00
|
|
|
if (conn->sslmode)
|
|
|
|
free(conn->sslmode);
|
2008-12-15 11:28:22 +01:00
|
|
|
if (conn->sslcert)
|
|
|
|
free(conn->sslcert);
|
|
|
|
if (conn->sslkey)
|
|
|
|
free(conn->sslkey);
|
|
|
|
if (conn->sslrootcert)
|
|
|
|
free(conn->sslrootcert);
|
|
|
|
if (conn->sslcrl)
|
|
|
|
free(conn->sslcrl);
|
2012-02-01 16:51:35 +01:00
|
|
|
if (conn->sslcompression)
|
|
|
|
free(conn->sslcompression);
|
2010-07-18 13:37:26 +02:00
|
|
|
if (conn->requirepeer)
|
|
|
|
free(conn->requirepeer);
|
2014-01-15 17:24:01 +01:00
|
|
|
#if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
|
2005-06-04 22:42:43 +02:00
|
|
|
if (conn->krbsrvname)
|
|
|
|
free(conn->krbsrvname);
|
2008-10-23 18:17:19 +02:00
|
|
|
#endif
|
|
|
|
#if defined(ENABLE_GSS) && defined(ENABLE_SSPI)
|
|
|
|
if (conn->gsslib)
|
|
|
|
free(conn->gsslib);
|
2005-06-04 22:42:43 +02:00
|
|
|
#endif
|
1998-05-07 01:51:16 +02:00
|
|
|
/* Note that conn->Pfdebug is not ours to close or free */
|
2006-03-14 23:48:25 +01:00
|
|
|
if (conn->last_query)
|
|
|
|
free(conn->last_query);
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->inBuffer)
|
|
|
|
free(conn->inBuffer);
|
|
|
|
if (conn->outBuffer)
|
|
|
|
free(conn->outBuffer);
|
2012-04-05 00:27:56 +02:00
|
|
|
if (conn->rowBuf)
|
|
|
|
free(conn->rowBuf);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
if (conn->target_session_attrs)
|
|
|
|
free(conn->target_session_attrs);
|
1999-08-31 03:37:37 +02:00
|
|
|
termPQExpBuffer(&conn->errorMessage);
|
|
|
|
termPQExpBuffer(&conn->workBuffer);
|
2008-01-29 03:06:30 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
free(conn);
|
2007-03-08 20:27:28 +01:00
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
WSACleanup();
|
|
|
|
#endif
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
* release_all_addrinfo
|
|
|
|
* - free addrinfo of all hostconn elements.
|
2003-06-21 23:51:35 +02:00
|
|
|
*/
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
static void
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
release_all_addrinfo(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
if (conn->connhost != NULL)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < conn->nconnhost; ++i)
|
|
|
|
{
|
|
|
|
int family = AF_UNSPEC;
|
|
|
|
|
|
|
|
#ifdef HAVE_UNIX_SOCKETS
|
|
|
|
if (conn->connhost[i].type == CHT_UNIX_SOCKET)
|
|
|
|
family = AF_UNIX;
|
|
|
|
#endif
|
2005-07-13 17:25:55 +02:00
|
|
|
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
pg_freeaddrinfo_all(family,
|
|
|
|
conn->connhost[i].addrlist);
|
|
|
|
conn->connhost[i].addrlist = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
conn->addr_cur = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* sendTerminateConn
|
|
|
|
* - Send a terminate message to backend.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
sendTerminateConn(PGconn *conn)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
/*
|
|
|
|
* Note that the protocol doesn't allow us to send Terminate messages
|
|
|
|
* during the startup phase.
|
|
|
|
*/
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock != PGINVALID_SOCKET && conn->status == CONNECTION_OK)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
|
|
|
/*
|
1998-09-01 06:40:42 +02:00
|
|
|
* Try to send "close connection" message to backend. Ignore any
|
2003-04-19 02:02:30 +02:00
|
|
|
* error.
|
1998-05-07 01:51:16 +02:00
|
|
|
*/
|
2003-06-08 19:43:00 +02:00
|
|
|
pqPutMsgStart('X', false, conn);
|
2003-04-19 02:02:30 +02:00
|
|
|
pqPutMsgEnd(conn);
|
2014-03-02 04:14:14 +01:00
|
|
|
(void) pqFlush(conn);
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* closePGconn
|
|
|
|
* - properly close a connection to the backend
|
|
|
|
*
|
|
|
|
* This should reset or release all transient state, but NOT the connection
|
|
|
|
* parameters. On exit, the PGconn should be in condition to start a fresh
|
|
|
|
* connection with the same parameters (see PQreset()).
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
closePGconn(PGconn *conn)
|
|
|
|
{
|
|
|
|
PGnotify *notify;
|
|
|
|
pgParameterStatus *pstatus;
|
|
|
|
|
|
|
|
sendTerminateConn(conn);
|
1998-05-07 01:51:16 +02:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2008-01-29 03:06:30 +01:00
|
|
|
* Must reset the blocking status so a possible reconnect will work.
|
|
|
|
*
|
|
|
|
* Don't call PQsetnonblocking() because it will fail if it's unable to
|
|
|
|
* flush the connection.
|
2000-01-24 03:12:58 +01:00
|
|
|
*/
|
2017-08-16 06:22:32 +02:00
|
|
|
conn->nonblocking = false;
|
2000-01-24 03:12:58 +01:00
|
|
|
|
1998-05-07 01:51:16 +02:00
|
|
|
/*
|
|
|
|
* Close the connection, reset all transient state, flush I/O buffers.
|
|
|
|
*/
|
2015-11-12 19:03:52 +01:00
|
|
|
pqDropConnection(conn, true);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
conn->status = CONNECTION_BAD; /* Well, not really _bad_ - just absent */
|
1998-05-07 01:51:16 +02:00
|
|
|
conn->asyncStatus = PGASYNC_IDLE;
|
2012-04-05 00:27:56 +02:00
|
|
|
pqClearAsyncResult(conn); /* deallocate result */
|
2014-10-29 13:32:01 +01:00
|
|
|
resetPQExpBuffer(&conn->errorMessage);
|
libpq: Add target_session_attrs parameter.
Commit 274bb2b3857cc987cfa21d14775cae9b0dababa5 made it possible to
specify multiple IPs in a connection string, but that's not good
enough for the case where you have a read-write master and a bunch of
read-only standbys and want to connect to whichever server is the
master at the current time. This commit allows that, by making it
possible to specify target_session_attrs=read-write as a connection
parameter.
There was extensive discussion of the best name for the connection
parameter and its values as well as the best way to distinguish master
and standbys. For now, adopt the same solution as JDBC: if the user
wants a read-write connection, issue 'show transaction_read_only' and
rejection the connection if the result is 'on'. In the future, we
could add additional values of this new target_session_attrs parameter
that issue different queries; or we might have some way of
distinguishing the server type without resorting to an SQL query; but
right now, we have this, and that's (hopefully) a good start.
Victor Wagner and Mithun Cy. Design review by Álvaro Herrera, Catalin
Iacob, Takayuki Tsunakawa, and Craig Ringer; code review by me. I
changed Mithun's patch to skip all remaining IPs for a host if we
reject a connection based on this new parameter, rewrote the
documentation, and did some other cosmetic cleanup.
Discussion: http://postgr.es/m/CAD__OuhqPRGpcsfwPHz_PDqAGkoqS1UvnUnOnAB-LBWBW=wu4A@mail.gmail.com
2016-11-29 18:18:31 +01:00
|
|
|
release_all_addrinfo(conn);
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2005-07-13 17:25:55 +02:00
|
|
|
notify = conn->notifyHead;
|
|
|
|
while (notify != NULL)
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
PGnotify *prev = notify;
|
2005-07-13 17:25:55 +02:00
|
|
|
|
|
|
|
notify = notify->next;
|
|
|
|
free(prev);
|
|
|
|
}
|
2008-01-29 03:06:30 +01:00
|
|
|
conn->notifyHead = conn->notifyTail = NULL;
|
2005-07-13 17:25:55 +02:00
|
|
|
pstatus = conn->pstatus;
|
|
|
|
while (pstatus != NULL)
|
|
|
|
{
|
|
|
|
pgParameterStatus *prev = pstatus;
|
|
|
|
|
|
|
|
pstatus = pstatus->next;
|
|
|
|
free(prev);
|
|
|
|
}
|
|
|
|
conn->pstatus = NULL;
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn->lobjfuncs)
|
|
|
|
free(conn->lobjfuncs);
|
|
|
|
conn->lobjfuncs = NULL;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-06-12 02:00:21 +02:00
|
|
|
* PQfinish: properly close a connection to the backend. Also frees
|
|
|
|
* the PGconn data structure so it shouldn't be re-used after this.
|
|
|
|
*/
|
1996-07-09 08:22:35 +02:00
|
|
|
void
|
1997-09-08 23:56:23 +02:00
|
|
|
PQfinish(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-08-09 04:59:33 +02:00
|
|
|
if (conn)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
closePGconn(conn);
|
1997-09-07 07:04:48 +02:00
|
|
|
freePGconn(conn);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-12 02:00:21 +02:00
|
|
|
/*
|
|
|
|
* PQreset: resets the connection to the backend by closing the
|
|
|
|
* existing connection and creating a new one.
|
|
|
|
*/
|
1996-07-09 08:22:35 +02:00
|
|
|
void
|
1997-09-08 23:56:23 +02:00
|
|
|
PQreset(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-08-09 04:59:33 +02:00
|
|
|
if (conn)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
closePGconn(conn);
|
1999-11-30 04:08:19 +01:00
|
|
|
|
2008-09-17 06:31:08 +02:00
|
|
|
if (connectDBStart(conn) && connectDBComplete(conn))
|
|
|
|
{
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Notify event procs of successful reset. We treat an event proc
|
2009-06-11 16:49:15 +02:00
|
|
|
* failure as disabling the connection ... good idea?
|
2008-09-17 06:31:08 +02:00
|
|
|
*/
|
2009-06-11 16:49:15 +02:00
|
|
|
int i;
|
2008-09-17 06:31:08 +02:00
|
|
|
|
|
|
|
for (i = 0; i < conn->nEvents; i++)
|
|
|
|
{
|
|
|
|
PGEventConnReset evt;
|
|
|
|
|
|
|
|
evt.conn = conn;
|
|
|
|
if (!conn->events[i].proc(PGEVT_CONNRESET, &evt,
|
|
|
|
conn->events[i].passThrough))
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("PGEventProc \"%s\" failed during PGEVT_CONNRESET event\n"),
|
|
|
|
conn->events[i].name);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-06-12 02:00:21 +02:00
|
|
|
/*
|
|
|
|
* PQresetStart:
|
|
|
|
* resets the connection to the backend
|
|
|
|
* closes the existing connection and makes a new one
|
|
|
|
* Returns 1 on success, 0 on failure.
|
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
int
|
|
|
|
PQresetStart(PGconn *conn)
|
|
|
|
{
|
|
|
|
if (conn)
|
|
|
|
{
|
|
|
|
closePGconn(conn);
|
|
|
|
|
|
|
|
return connectDBStart(conn);
|
|
|
|
}
|
|
|
|
|
2000-01-14 06:33:15 +01:00
|
|
|
return 0;
|
1999-11-30 04:08:19 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-06-12 02:00:21 +02:00
|
|
|
/*
|
|
|
|
* PQresetPoll:
|
|
|
|
* resets the connection to the backend
|
|
|
|
* closes the existing connection and makes a new one
|
|
|
|
*/
|
1999-11-30 04:08:19 +01:00
|
|
|
PostgresPollingStatusType
|
|
|
|
PQresetPoll(PGconn *conn)
|
|
|
|
{
|
|
|
|
if (conn)
|
2008-09-17 06:31:08 +02:00
|
|
|
{
|
|
|
|
PostgresPollingStatusType status = PQconnectPoll(conn);
|
|
|
|
|
|
|
|
if (status == PGRES_POLLING_OK)
|
|
|
|
{
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Notify event procs of successful reset. We treat an event proc
|
2009-06-11 16:49:15 +02:00
|
|
|
* failure as disabling the connection ... good idea?
|
2008-09-17 06:31:08 +02:00
|
|
|
*/
|
2009-06-11 16:49:15 +02:00
|
|
|
int i;
|
2008-09-17 06:31:08 +02:00
|
|
|
|
|
|
|
for (i = 0; i < conn->nEvents; i++)
|
|
|
|
{
|
|
|
|
PGEventConnReset evt;
|
|
|
|
|
|
|
|
evt.conn = conn;
|
|
|
|
if (!conn->events[i].proc(PGEVT_CONNRESET, &evt,
|
|
|
|
conn->events[i].passThrough))
|
|
|
|
{
|
|
|
|
conn->status = CONNECTION_BAD;
|
|
|
|
printfPQExpBuffer(&conn->errorMessage,
|
|
|
|
libpq_gettext("PGEventProc \"%s\" failed during PGEVT_CONNRESET event\n"),
|
|
|
|
conn->events[i].name);
|
|
|
|
return PGRES_POLLING_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
1999-11-30 04:08:19 +01:00
|
|
|
|
|
|
|
return PGRES_POLLING_FAILED;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2004-10-31 01:11:27 +02:00
|
|
|
/*
|
2016-04-05 11:05:01 +02:00
|
|
|
* PQgetCancel: get a PGcancel structure corresponding to a connection.
|
2004-10-31 01:11:27 +02:00
|
|
|
*
|
|
|
|
* A copy is needed to be able to cancel a running query from a different
|
|
|
|
* thread. If the same structure is used all structure members would have
|
|
|
|
* to be individually locked (if the entire structure was locked, it would
|
2006-05-19 16:26:58 +02:00
|
|
|
* be impossible to cancel a synchronous query because the structure would
|
2004-10-31 01:11:27 +02:00
|
|
|
* have to stay locked for the duration of the query).
|
|
|
|
*/
|
|
|
|
PGcancel *
|
|
|
|
PQgetCancel(PGconn *conn)
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
PGcancel *cancel;
|
2004-10-31 01:11:27 +02:00
|
|
|
|
|
|
|
if (!conn)
|
|
|
|
return NULL;
|
|
|
|
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
2004-10-31 01:11:27 +02:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
cancel = malloc(sizeof(PGcancel));
|
|
|
|
if (cancel == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
memcpy(&cancel->raddr, &conn->raddr, sizeof(SockAddr));
|
|
|
|
cancel->be_pid = conn->be_pid;
|
|
|
|
cancel->be_key = conn->be_key;
|
|
|
|
|
|
|
|
return cancel;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* PQfreeCancel: free a cancel structure */
|
|
|
|
void
|
|
|
|
PQfreeCancel(PGcancel *cancel)
|
|
|
|
{
|
|
|
|
if (cancel)
|
|
|
|
free(cancel);
|
|
|
|
}
|
|
|
|
|
1998-07-09 05:29:11 +02:00
|
|
|
|
|
|
|
/*
|
2004-10-31 01:11:27 +02:00
|
|
|
* PQcancel and PQrequestCancel: attempt to request cancellation of the
|
|
|
|
* current operation.
|
1998-07-09 05:29:11 +02:00
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* The return value is true if the cancel request was successfully
|
|
|
|
* dispatched, false if not (in which case an error message is available).
|
1998-07-09 05:29:11 +02:00
|
|
|
* Note: successful dispatch is no guarantee that there will be any effect at
|
|
|
|
* the backend. The application must read the operation result as usual.
|
|
|
|
*
|
|
|
|
* CAUTION: we want this routine to be safely callable from a signal handler
|
|
|
|
* (for example, an application might want to call it in a SIGINT handler).
|
|
|
|
* This means we cannot use any C library routine that might be non-reentrant.
|
|
|
|
* malloc/free are often non-reentrant, and anything that might call them is
|
|
|
|
* just as dangerous. We avoid sprintf here for that reason. Building up
|
|
|
|
* error messages with strcpy/strcat is tedious but should be quite safe.
|
2000-12-18 18:33:42 +01:00
|
|
|
* We also save/restore errno in case the signal handler support doesn't.
|
1999-08-31 03:37:37 +02:00
|
|
|
*
|
2004-10-31 01:11:27 +02:00
|
|
|
* internal_cancel() is an internal helper function to make code-sharing
|
|
|
|
* between the two versions of the cancel function possible.
|
1998-07-09 05:29:11 +02:00
|
|
|
*/
|
2004-10-31 01:11:27 +02:00
|
|
|
static int
|
|
|
|
internal_cancel(SockAddr *raddr, int be_pid, int be_key,
|
|
|
|
char *errbuf, int errbufsize)
|
1998-07-09 05:29:11 +02:00
|
|
|
{
|
2001-08-21 22:39:54 +02:00
|
|
|
int save_errno = SOCK_ERRNO;
|
2014-04-16 16:45:48 +02:00
|
|
|
pgsocket tmpsock = PGINVALID_SOCKET;
|
2003-06-14 19:49:54 +02:00
|
|
|
char sebuf[256];
|
2005-10-15 04:49:52 +02:00
|
|
|
int maxlen;
|
1998-09-01 06:40:42 +02:00
|
|
|
struct
|
|
|
|
{
|
|
|
|
uint32 packetlen;
|
|
|
|
CancelRequestPacket cp;
|
1998-07-09 05:29:11 +02:00
|
|
|
} crp;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We need to open a temporary connection to the postmaster. Do this with
|
|
|
|
* only kernel calls.
|
1998-07-09 05:29:11 +02:00
|
|
|
*/
|
2014-04-16 16:45:48 +02:00
|
|
|
if ((tmpsock = socket(raddr->addr.ss_family, SOCK_STREAM, 0)) == PGINVALID_SOCKET)
|
1998-07-09 05:29:11 +02:00
|
|
|
{
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(errbuf, "PQcancel() -- socket() failed: ", errbufsize);
|
1998-07-09 05:29:11 +02:00
|
|
|
goto cancel_errReturn;
|
|
|
|
}
|
2002-04-16 01:34:17 +02:00
|
|
|
retry3:
|
2017-06-21 20:39:04 +02:00
|
|
|
if (connect(tmpsock, (struct sockaddr *) &raddr->addr,
|
2004-10-31 01:11:27 +02:00
|
|
|
raddr->salen) < 0)
|
1998-07-09 05:29:11 +02:00
|
|
|
{
|
2002-04-16 01:34:17 +02:00
|
|
|
if (SOCK_ERRNO == EINTR)
|
|
|
|
/* Interrupted system call - we'll just try again */
|
|
|
|
goto retry3;
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(errbuf, "PQcancel() -- connect() failed: ", errbufsize);
|
1998-07-09 05:29:11 +02:00
|
|
|
goto cancel_errReturn;
|
|
|
|
}
|
1998-09-01 06:40:42 +02:00
|
|
|
|
1998-07-09 05:29:11 +02:00
|
|
|
/*
|
|
|
|
* We needn't set nonblocking I/O or NODELAY options here.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Create and send the cancel request packet. */
|
|
|
|
|
2017-10-02 00:36:14 +02:00
|
|
|
crp.packetlen = pg_hton32((uint32) sizeof(crp));
|
|
|
|
crp.cp.cancelRequestCode = (MsgType) pg_hton32(CANCEL_REQUEST_CODE);
|
|
|
|
crp.cp.backendPID = pg_hton32(be_pid);
|
|
|
|
crp.cp.cancelAuthCode = pg_hton32(be_key);
|
1998-07-09 05:29:11 +02:00
|
|
|
|
2002-04-16 01:34:17 +02:00
|
|
|
retry4:
|
1998-09-01 06:40:42 +02:00
|
|
|
if (send(tmpsock, (char *) &crp, sizeof(crp), 0) != (int) sizeof(crp))
|
1998-07-09 05:29:11 +02:00
|
|
|
{
|
2002-04-16 01:34:17 +02:00
|
|
|
if (SOCK_ERRNO == EINTR)
|
|
|
|
/* Interrupted system call - we'll just try again */
|
|
|
|
goto retry4;
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(errbuf, "PQcancel() -- send() failed: ", errbufsize);
|
1998-07-09 05:29:11 +02:00
|
|
|
goto cancel_errReturn;
|
|
|
|
}
|
|
|
|
|
2003-10-02 21:52:44 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Wait for the postmaster to close the connection, which indicates that
|
|
|
|
* it's processed the request. Without this delay, we might issue another
|
|
|
|
* command only to find that our cancel zaps that command instead of the
|
|
|
|
* one we thought we were canceling. Note we don't actually expect this
|
|
|
|
* read to obtain any data, we are just waiting for EOF to be signaled.
|
2003-10-02 21:52:44 +02:00
|
|
|
*/
|
|
|
|
retry5:
|
|
|
|
if (recv(tmpsock, (char *) &crp, 1, 0) < 0)
|
|
|
|
{
|
|
|
|
if (SOCK_ERRNO == EINTR)
|
|
|
|
/* Interrupted system call - we'll just try again */
|
|
|
|
goto retry5;
|
|
|
|
/* we ignore other error conditions */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* All done */
|
1998-07-09 05:29:11 +02:00
|
|
|
closesocket(tmpsock);
|
2005-01-05 00:18:25 +01:00
|
|
|
SOCK_ERRNO_SET(save_errno);
|
2017-08-16 06:22:32 +02:00
|
|
|
return true;
|
1998-07-09 05:29:11 +02:00
|
|
|
|
|
|
|
cancel_errReturn:
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2004-10-31 01:11:27 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Make sure we don't overflow the error buffer. Leave space for the \n at
|
|
|
|
* the end, and for the terminating zero.
|
2004-10-31 01:11:27 +02:00
|
|
|
*/
|
|
|
|
maxlen = errbufsize - strlen(errbuf) - 2;
|
|
|
|
if (maxlen >= 0)
|
1998-07-09 05:29:11 +02:00
|
|
|
{
|
2004-10-31 01:11:27 +02:00
|
|
|
strncat(errbuf, SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)),
|
|
|
|
maxlen);
|
|
|
|
strcat(errbuf, "\n");
|
|
|
|
}
|
2014-04-16 16:45:48 +02:00
|
|
|
if (tmpsock != PGINVALID_SOCKET)
|
1998-07-09 05:29:11 +02:00
|
|
|
closesocket(tmpsock);
|
2005-01-05 00:18:25 +01:00
|
|
|
SOCK_ERRNO_SET(save_errno);
|
2017-08-16 06:22:32 +02:00
|
|
|
return false;
|
1998-07-09 05:29:11 +02:00
|
|
|
}
|
|
|
|
|
2004-10-31 01:11:27 +02:00
|
|
|
/*
|
|
|
|
* PQcancel: request query cancel
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* Returns true if able to send the cancel request, false if not.
|
2004-10-31 01:11:27 +02:00
|
|
|
*
|
|
|
|
* On failure, an error message is stored in *errbuf, which must be of size
|
2014-05-06 18:12:18 +02:00
|
|
|
* errbufsize (recommended size is 256 bytes). *errbuf is not changed on
|
2004-10-31 01:11:27 +02:00
|
|
|
* success return.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
PQcancel(PGcancel *cancel, char *errbuf, int errbufsize)
|
|
|
|
{
|
|
|
|
if (!cancel)
|
|
|
|
{
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(errbuf, "PQcancel() -- no cancel object supplied", errbufsize);
|
2017-08-16 06:22:32 +02:00
|
|
|
return false;
|
2004-10-31 01:11:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return internal_cancel(&cancel->raddr, cancel->be_pid, cancel->be_key,
|
|
|
|
errbuf, errbufsize);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PQrequestCancel: old, not thread-safe function for requesting query cancel
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* Returns true if able to send the cancel request, false if not.
|
2004-10-31 01:11:27 +02:00
|
|
|
*
|
|
|
|
* On failure, the error message is saved in conn->errorMessage; this means
|
|
|
|
* that this can't be used when there might be other active operations on
|
|
|
|
* the connection object.
|
|
|
|
*
|
|
|
|
* NOTE: error messages will be cut off at the current size of the
|
|
|
|
* error message buffer, since we dare not try to expand conn->errorMessage!
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
PQrequestCancel(PGconn *conn)
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
int r;
|
2004-10-31 01:11:27 +02:00
|
|
|
|
|
|
|
/* Check we have an open connection */
|
|
|
|
if (!conn)
|
2017-08-16 06:22:32 +02:00
|
|
|
return false;
|
2004-10-31 01:11:27 +02:00
|
|
|
|
2014-04-17 01:46:51 +02:00
|
|
|
if (conn->sock == PGINVALID_SOCKET)
|
2004-10-31 01:11:27 +02:00
|
|
|
{
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(conn->errorMessage.data,
|
2004-10-31 01:11:27 +02:00
|
|
|
"PQrequestCancel() -- connection is not open\n",
|
|
|
|
conn->errorMessage.maxlen);
|
|
|
|
conn->errorMessage.len = strlen(conn->errorMessage.data);
|
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
return false;
|
2004-10-31 01:11:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
r = internal_cancel(&conn->raddr, conn->be_pid, conn->be_key,
|
|
|
|
conn->errorMessage.data, conn->errorMessage.maxlen);
|
|
|
|
|
|
|
|
if (!r)
|
|
|
|
conn->errorMessage.len = strlen(conn->errorMessage.data);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
1998-07-09 05:29:11 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2003-04-19 02:02:30 +02:00
|
|
|
* pqPacketSend() -- convenience routine to send a message to server.
|
2003-04-18 00:26:02 +02:00
|
|
|
*
|
|
|
|
* pack_type: the single-byte message type code. (Pass zero for startup
|
|
|
|
* packets, which have no message type code.)
|
|
|
|
*
|
|
|
|
* buf, buf_len: contents of message. The given length includes only what
|
|
|
|
* is in buf; the message type and message length fields are added here.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* RETURNS: STATUS_ERROR if the write fails, STATUS_OK otherwise.
|
|
|
|
* SIDE_EFFECTS: may block.
|
2003-06-08 19:43:00 +02:00
|
|
|
*
|
|
|
|
* Note: all messages sent with this routine have a length word, whether
|
|
|
|
* it's protocol 2.0 or 3.0.
|
|
|
|
*/
|
1997-03-12 22:23:16 +01:00
|
|
|
int
|
2003-04-18 00:26:02 +02:00
|
|
|
pqPacketSend(PGconn *conn, char pack_type,
|
|
|
|
const void *buf, size_t buf_len)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-04-19 02:02:30 +02:00
|
|
|
/* Start the message. */
|
2003-06-08 19:43:00 +02:00
|
|
|
if (pqPutMsgStart(pack_type, true, conn))
|
1998-01-26 02:42:53 +01:00
|
|
|
return STATUS_ERROR;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/* Send the message body. */
|
|
|
|
if (pqPutnchar(buf, buf_len, conn))
|
1998-01-26 02:42:53 +01:00
|
|
|
return STATUS_ERROR;
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2003-04-19 02:02:30 +02:00
|
|
|
/* Finish the message. */
|
|
|
|
if (pqPutMsgEnd(conn))
|
|
|
|
return STATUS_ERROR;
|
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/* Flush to ensure backend gets it. */
|
1998-05-07 01:51:16 +02:00
|
|
|
if (pqFlush(conn))
|
|
|
|
return STATUS_ERROR;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-01-26 02:42:53 +01:00
|
|
|
return STATUS_OK;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
#ifdef USE_LDAP
|
|
|
|
|
|
|
|
#define LDAP_URL "ldap://"
|
|
|
|
#define LDAP_DEF_PORT 389
|
|
|
|
#define PGLDAP_TIMEOUT 2
|
|
|
|
|
|
|
|
#define ld_is_sp_tab(x) ((x) == ' ' || (x) == '\t')
|
|
|
|
#define ld_is_nl_cr(x) ((x) == '\r' || (x) == '\n')
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ldapServiceLookup
|
|
|
|
*
|
|
|
|
* Search the LDAP URL passed as first argument, treat the result as a
|
|
|
|
* string of connection options that are parsed and added to the array of
|
|
|
|
* options passed as second argument.
|
|
|
|
*
|
|
|
|
* LDAP URLs must conform to RFC 1959 without escape sequences.
|
|
|
|
* ldap://host:port/dn?attributes?scope?filter?extensions
|
|
|
|
*
|
|
|
|
* Returns
|
|
|
|
* 0 if the lookup was successful,
|
|
|
|
* 1 if the connection to the LDAP server could be established but
|
|
|
|
* the search was unsuccessful,
|
|
|
|
* 2 if a connection could not be established, and
|
|
|
|
* 3 if a fatal error occurred.
|
|
|
|
*
|
|
|
|
* An error message is returned in the third argument for return codes 1 and 3.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ldapServiceLookup(const char *purl, PQconninfoOption *options,
|
|
|
|
PQExpBuffer errorMessage)
|
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
int port = LDAP_DEF_PORT,
|
|
|
|
scope,
|
|
|
|
rc,
|
|
|
|
size,
|
|
|
|
state,
|
|
|
|
oldstate,
|
|
|
|
i;
|
2014-04-17 22:12:24 +02:00
|
|
|
#ifndef WIN32
|
|
|
|
int msgid;
|
|
|
|
#endif
|
2006-07-27 15:20:24 +02:00
|
|
|
bool found_keyword;
|
2006-10-04 02:30:14 +02:00
|
|
|
char *url,
|
|
|
|
*hostname,
|
|
|
|
*portstr,
|
|
|
|
*endptr,
|
|
|
|
*dn,
|
|
|
|
*scopestr,
|
|
|
|
*filter,
|
|
|
|
*result,
|
|
|
|
*p,
|
|
|
|
*p1 = NULL,
|
|
|
|
*optname = NULL,
|
|
|
|
*optval = NULL;
|
2006-07-27 15:20:24 +02:00
|
|
|
char *attrs[2] = {NULL, NULL};
|
|
|
|
LDAP *ld = NULL;
|
2006-10-04 02:30:14 +02:00
|
|
|
LDAPMessage *res,
|
|
|
|
*entry;
|
2006-07-27 15:20:24 +02:00
|
|
|
struct berval **values;
|
|
|
|
LDAP_TIMEVAL time = {PGLDAP_TIMEOUT, 0};
|
|
|
|
|
|
|
|
if ((url = strdup(purl)) == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("out of memory\n"));
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Parse URL components, check for correctness. Basically, url has '\0'
|
|
|
|
* placed at component boundaries and variables are pointed at each
|
|
|
|
* component.
|
2006-07-27 15:20:24 +02:00
|
|
|
*/
|
|
|
|
|
2006-09-15 23:34:23 +02:00
|
|
|
if (pg_strncasecmp(url, LDAP_URL, strlen(LDAP_URL)) != 0)
|
2006-07-27 15:20:24 +02:00
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
2007-11-15 22:14:46 +01:00
|
|
|
libpq_gettext("invalid LDAP URL \"%s\": scheme must be ldap://\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* hostname */
|
|
|
|
hostname = url + strlen(LDAP_URL);
|
2006-10-04 02:30:14 +02:00
|
|
|
if (*hostname == '/') /* no hostname? */
|
2010-12-18 17:25:41 +01:00
|
|
|
hostname = DefaultHost; /* the default */
|
2006-07-27 15:20:24 +02:00
|
|
|
|
|
|
|
/* dn, "distinguished name" */
|
2006-10-04 02:30:14 +02:00
|
|
|
p = strchr(url + strlen(LDAP_URL), '/');
|
2006-07-27 15:20:24 +02:00
|
|
|
if (p == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"invalid LDAP URL \"%s\": missing distinguished name\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
2006-10-04 02:30:14 +02:00
|
|
|
*p = '\0'; /* terminate hostname */
|
2006-07-27 15:20:24 +02:00
|
|
|
dn = p + 1;
|
|
|
|
|
|
|
|
/* attribute */
|
|
|
|
if ((p = strchr(dn, '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"invalid LDAP URL \"%s\": must have exactly one attribute\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
*p = '\0';
|
|
|
|
attrs[0] = p + 1;
|
|
|
|
|
|
|
|
/* scope */
|
|
|
|
if ((p = strchr(attrs[0], '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
|
|
|
|
{
|
2006-10-06 19:14:01 +02:00
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("invalid LDAP URL \"%s\": must have search scope (base/one/sub)\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
*p = '\0';
|
|
|
|
scopestr = p + 1;
|
|
|
|
|
|
|
|
/* filter */
|
|
|
|
if ((p = strchr(scopestr, '?')) == NULL || *(p + 1) == '\0' || *(p + 1) == '?')
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid LDAP URL \"%s\": no filter\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
*p = '\0';
|
|
|
|
filter = p + 1;
|
|
|
|
if ((p = strchr(filter, '?')) != NULL)
|
|
|
|
*p = '\0';
|
2000-10-17 19:43:13 +02:00
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
/* port number? */
|
|
|
|
if ((p1 = strchr(hostname, ':')) != NULL)
|
|
|
|
{
|
|
|
|
long lport;
|
|
|
|
|
|
|
|
*p1 = '\0';
|
|
|
|
portstr = p1 + 1;
|
|
|
|
errno = 0;
|
|
|
|
lport = strtol(portstr, &endptr, 10);
|
|
|
|
if (*portstr == '\0' || *endptr != '\0' || errno || lport < 0 || lport > 65535)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"invalid LDAP URL \"%s\": invalid port number\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
port = (int) lport;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allow only one attribute */
|
|
|
|
if (strchr(attrs[0], ',') != NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"invalid LDAP URL \"%s\": must have exactly one attribute\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set scope */
|
2006-09-15 23:34:23 +02:00
|
|
|
if (pg_strcasecmp(scopestr, "base") == 0)
|
2006-07-27 15:20:24 +02:00
|
|
|
scope = LDAP_SCOPE_BASE;
|
2006-09-15 23:34:23 +02:00
|
|
|
else if (pg_strcasecmp(scopestr, "one") == 0)
|
2006-07-27 15:20:24 +02:00
|
|
|
scope = LDAP_SCOPE_ONELEVEL;
|
2006-09-15 23:34:23 +02:00
|
|
|
else if (pg_strcasecmp(scopestr, "sub") == 0)
|
2006-07-27 15:20:24 +02:00
|
|
|
scope = LDAP_SCOPE_SUBTREE;
|
|
|
|
else
|
|
|
|
{
|
2006-10-06 19:14:01 +02:00
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("invalid LDAP URL \"%s\": must have search scope (base/one/sub)\n"), purl);
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize LDAP structure */
|
|
|
|
if ((ld = ldap_init(hostname, port)) == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
2006-10-06 19:14:01 +02:00
|
|
|
libpq_gettext("could not create LDAP structure\n"));
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-04-16 17:18:02 +02:00
|
|
|
* Perform an explicit anonymous bind.
|
2014-04-17 22:12:24 +02:00
|
|
|
*
|
|
|
|
* LDAP does not require that an anonymous bind is performed explicitly,
|
2014-04-16 17:18:02 +02:00
|
|
|
* but we want to distinguish between the case where LDAP bind does not
|
2014-05-06 18:12:18 +02:00
|
|
|
* succeed within PGLDAP_TIMEOUT seconds (return 2 to continue parsing the
|
|
|
|
* service control file) and the case where querying the LDAP server fails
|
|
|
|
* (return 1 to end parsing).
|
2014-04-17 22:12:24 +02:00
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Unfortunately there is no way of setting a timeout that works for both
|
|
|
|
* Windows and OpenLDAP.
|
2006-07-27 15:20:24 +02:00
|
|
|
*/
|
2014-04-16 17:18:02 +02:00
|
|
|
#ifdef WIN32
|
|
|
|
/* the nonstandard ldap_connect function performs an anonymous bind */
|
|
|
|
if (ldap_connect(ld, &time) != LDAP_SUCCESS)
|
|
|
|
{
|
|
|
|
/* error or timeout in ldap_connect */
|
|
|
|
free(url);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 2;
|
|
|
|
}
|
2014-05-06 18:12:18 +02:00
|
|
|
#else /* !WIN32 */
|
2014-04-16 17:18:02 +02:00
|
|
|
/* in OpenLDAP, use the LDAP_OPT_NETWORK_TIMEOUT option */
|
|
|
|
if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, &time) != LDAP_SUCCESS)
|
|
|
|
{
|
|
|
|
free(url);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* anonymous bind */
|
2006-07-27 15:20:24 +02:00
|
|
|
if ((msgid = ldap_simple_bind(ld, NULL, NULL)) == -1)
|
|
|
|
{
|
2014-04-16 17:18:02 +02:00
|
|
|
/* error or network timeout */
|
2006-07-27 15:20:24 +02:00
|
|
|
free(url);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* wait some time for the connection to succeed */
|
|
|
|
res = NULL;
|
|
|
|
if ((rc = ldap_result(ld, msgid, LDAP_MSG_ALL, &time, &res)) == -1 ||
|
|
|
|
res == NULL)
|
|
|
|
{
|
2014-04-16 17:18:02 +02:00
|
|
|
/* error or timeout */
|
2006-07-27 15:20:24 +02:00
|
|
|
if (res != NULL)
|
|
|
|
ldap_msgfree(res);
|
|
|
|
free(url);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
ldap_msgfree(res);
|
|
|
|
|
2014-04-16 17:18:02 +02:00
|
|
|
/* reset timeout */
|
|
|
|
time.tv_sec = -1;
|
|
|
|
if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, &time) != LDAP_SUCCESS)
|
|
|
|
{
|
|
|
|
free(url);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 3;
|
|
|
|
}
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* WIN32 */
|
2014-04-16 17:18:02 +02:00
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
/* search */
|
|
|
|
res = NULL;
|
|
|
|
if ((rc = ldap_search_st(ld, dn, scope, filter, attrs, 0, &time, &res))
|
|
|
|
!= LDAP_SUCCESS)
|
|
|
|
{
|
|
|
|
if (res != NULL)
|
|
|
|
ldap_msgfree(res);
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("lookup on LDAP server failed: %s\n"),
|
|
|
|
ldap_err2string(rc));
|
|
|
|
ldap_unbind(ld);
|
|
|
|
free(url);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* complain if there was not exactly one result */
|
|
|
|
if ((rc = ldap_count_entries(ld, res)) != 1)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
rc ? libpq_gettext("more than one entry found on LDAP lookup\n")
|
2006-07-27 15:20:24 +02:00
|
|
|
: libpq_gettext("no entry found on LDAP lookup\n"));
|
|
|
|
ldap_msgfree(res);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
free(url);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get entry */
|
|
|
|
if ((entry = ldap_first_entry(ld, res)) == NULL)
|
|
|
|
{
|
|
|
|
/* should never happen */
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("no entry found on LDAP lookup\n"));
|
|
|
|
ldap_msgfree(res);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
free(url);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get values */
|
|
|
|
if ((values = ldap_get_values_len(ld, entry, attrs[0])) == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("attribute has no values on LDAP lookup\n"));
|
2006-07-27 15:20:24 +02:00
|
|
|
ldap_msgfree(res);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
free(url);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ldap_msgfree(res);
|
|
|
|
free(url);
|
|
|
|
|
|
|
|
if (values[0] == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("attribute has no values on LDAP lookup\n"));
|
2006-07-27 15:20:24 +02:00
|
|
|
ldap_value_free_len(values);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2011-05-12 17:56:38 +02:00
|
|
|
/* concatenate values into a single string with newline terminators */
|
|
|
|
size = 1; /* for the trailing null */
|
|
|
|
for (i = 0; values[i] != NULL; i++)
|
2006-07-27 15:20:24 +02:00
|
|
|
size += values[i]->bv_len + 1;
|
2011-05-12 17:56:38 +02:00
|
|
|
if ((result = malloc(size)) == NULL)
|
2006-07-27 15:20:24 +02:00
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
ldap_value_free_len(values);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
return 3;
|
|
|
|
}
|
2011-05-12 17:56:38 +02:00
|
|
|
p = result;
|
|
|
|
for (i = 0; values[i] != NULL; i++)
|
2006-07-27 15:20:24 +02:00
|
|
|
{
|
2011-05-12 17:56:38 +02:00
|
|
|
memcpy(p, values[i]->bv_val, values[i]->bv_len);
|
2006-07-27 15:20:24 +02:00
|
|
|
p += values[i]->bv_len;
|
|
|
|
*(p++) = '\n';
|
|
|
|
}
|
2011-05-12 17:56:38 +02:00
|
|
|
*p = '\0';
|
2006-07-27 15:20:24 +02:00
|
|
|
|
|
|
|
ldap_value_free_len(values);
|
|
|
|
ldap_unbind(ld);
|
|
|
|
|
|
|
|
/* parse result string */
|
|
|
|
oldstate = state = 0;
|
|
|
|
for (p = result; *p != '\0'; ++p)
|
|
|
|
{
|
|
|
|
switch (state)
|
|
|
|
{
|
|
|
|
case 0: /* between entries */
|
|
|
|
if (!ld_is_sp_tab(*p) && !ld_is_nl_cr(*p))
|
|
|
|
{
|
|
|
|
optname = p;
|
|
|
|
state = 1;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 1: /* in option name */
|
|
|
|
if (ld_is_sp_tab(*p))
|
|
|
|
{
|
|
|
|
*p = '\0';
|
|
|
|
state = 2;
|
|
|
|
}
|
|
|
|
else if (ld_is_nl_cr(*p))
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"missing \"=\" after \"%s\" in connection info string\n"),
|
2006-10-04 02:30:14 +02:00
|
|
|
optname);
|
2011-05-12 17:56:38 +02:00
|
|
|
free(result);
|
2006-07-27 15:20:24 +02:00
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
else if (*p == '=')
|
|
|
|
{
|
|
|
|
*p = '\0';
|
|
|
|
state = 3;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 2: /* after option name */
|
|
|
|
if (*p == '=')
|
|
|
|
{
|
|
|
|
state = 3;
|
|
|
|
}
|
|
|
|
else if (!ld_is_sp_tab(*p))
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"missing \"=\" after \"%s\" in connection info string\n"),
|
2006-10-04 02:30:14 +02:00
|
|
|
optname);
|
2011-05-12 17:56:38 +02:00
|
|
|
free(result);
|
2006-07-27 15:20:24 +02:00
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 3: /* before option value */
|
|
|
|
if (*p == '\'')
|
|
|
|
{
|
|
|
|
optval = p + 1;
|
|
|
|
p1 = p + 1;
|
|
|
|
state = 5;
|
|
|
|
}
|
|
|
|
else if (ld_is_nl_cr(*p))
|
|
|
|
{
|
|
|
|
optval = optname + strlen(optname); /* empty */
|
|
|
|
state = 0;
|
|
|
|
}
|
|
|
|
else if (!ld_is_sp_tab(*p))
|
|
|
|
{
|
|
|
|
optval = p;
|
|
|
|
state = 4;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 4: /* in unquoted option value */
|
|
|
|
if (ld_is_sp_tab(*p) || ld_is_nl_cr(*p))
|
|
|
|
{
|
|
|
|
*p = '\0';
|
|
|
|
state = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 5: /* in quoted option value */
|
|
|
|
if (*p == '\'')
|
|
|
|
{
|
|
|
|
*p1 = '\0';
|
|
|
|
state = 0;
|
|
|
|
}
|
|
|
|
else if (*p == '\\')
|
|
|
|
state = 6;
|
|
|
|
else
|
|
|
|
*(p1++) = *p;
|
|
|
|
break;
|
|
|
|
case 6: /* in quoted option value after escape */
|
|
|
|
*(p1++) = *p;
|
|
|
|
state = 5;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (state == 0 && oldstate != 0)
|
|
|
|
{
|
|
|
|
found_keyword = false;
|
|
|
|
for (i = 0; options[i].keyword; i++)
|
|
|
|
{
|
|
|
|
if (strcmp(options[i].keyword, optname) == 0)
|
|
|
|
{
|
|
|
|
if (options[i].val == NULL)
|
2014-11-25 11:55:00 +01:00
|
|
|
{
|
2006-07-27 15:20:24 +02:00
|
|
|
options[i].val = strdup(optval);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!options[i].val)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("out of memory\n"));
|
2014-11-25 11:55:00 +01:00
|
|
|
free(result);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
}
|
2006-07-27 15:20:24 +02:00
|
|
|
found_keyword = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!found_keyword)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid connection option \"%s\"\n"),
|
2006-10-04 02:30:14 +02:00
|
|
|
optname);
|
2011-05-12 17:56:38 +02:00
|
|
|
free(result);
|
2006-07-27 15:20:24 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
optname = NULL;
|
|
|
|
optval = NULL;
|
|
|
|
}
|
|
|
|
oldstate = state;
|
|
|
|
}
|
|
|
|
|
2011-05-12 17:56:38 +02:00
|
|
|
free(result);
|
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
if (state == 5 || state == 6)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext(
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
"unterminated quoted string in connection info string\n"));
|
2006-07-27 15:20:24 +02:00
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2014-04-17 22:12:24 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_LDAP */
|
2000-10-17 19:43:13 +02:00
|
|
|
|
2000-10-23 00:15:13 +02:00
|
|
|
#define MAXBUFSIZE 256
|
|
|
|
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
/*
|
|
|
|
* parseServiceInfo: if a service name has been given, look it up and absorb
|
|
|
|
* connection options from it into *options.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, nonzero on failure. On failure, if errorMessage
|
|
|
|
* isn't null, also store an error message there. (Note: the only reason
|
|
|
|
* this function and related ones don't dump core on errorMessage == NULL
|
|
|
|
* is the undocumented fact that printfPQExpBuffer does nothing when passed
|
|
|
|
* a null PQExpBuffer pointer.)
|
|
|
|
*/
|
2000-12-07 03:04:30 +01:00
|
|
|
static int
|
|
|
|
parseServiceInfo(PQconninfoOption *options, PQExpBuffer errorMessage)
|
|
|
|
{
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
const char *service = conninfo_getval(options, "service");
|
2004-06-03 02:07:38 +02:00
|
|
|
char serviceFile[MAXPGPATH];
|
2010-01-20 22:15:21 +01:00
|
|
|
char *env;
|
2003-12-19 22:50:54 +01:00
|
|
|
bool group_found = false;
|
2010-01-20 22:15:21 +01:00
|
|
|
int status;
|
|
|
|
struct stat stat_buf;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2003-04-28 06:52:13 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We have to special-case the environment variable PGSERVICE here, since
|
|
|
|
* this is and should be called before inserting environment defaults for
|
|
|
|
* other connection options.
|
2003-04-28 06:52:13 +02:00
|
|
|
*/
|
|
|
|
if (service == NULL)
|
|
|
|
service = getenv("PGSERVICE");
|
|
|
|
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
/* If no service name given, nothing to do */
|
2010-01-20 22:15:21 +01:00
|
|
|
if (service == NULL)
|
|
|
|
return 0;
|
|
|
|
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
/*
|
|
|
|
* Try PGSERVICEFILE if specified, else try ~/.pg_service.conf (if that
|
|
|
|
* exists).
|
|
|
|
*/
|
2010-01-20 22:15:21 +01:00
|
|
|
if ((env = getenv("PGSERVICEFILE")) != NULL)
|
|
|
|
strlcpy(serviceFile, env, sizeof(serviceFile));
|
|
|
|
else
|
|
|
|
{
|
|
|
|
char homedir[MAXPGPATH];
|
|
|
|
|
|
|
|
if (!pqGetHomeDirectory(homedir, sizeof(homedir)))
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
goto next_file;
|
2010-01-20 22:15:21 +01:00
|
|
|
snprintf(serviceFile, MAXPGPATH, "%s/%s", homedir, ".pg_service.conf");
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
if (stat(serviceFile, &stat_buf) != 0)
|
2010-01-20 22:15:21 +01:00
|
|
|
goto next_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = parseServiceFile(serviceFile, service, options, errorMessage, &group_found);
|
|
|
|
if (group_found || status != 0)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
next_file:
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2004-06-03 02:07:38 +02:00
|
|
|
/*
|
2004-08-29 07:07:03 +02:00
|
|
|
* This could be used by any application so we can't use the binary
|
|
|
|
* location to find our config files.
|
|
|
|
*/
|
2004-06-03 02:07:38 +02:00
|
|
|
snprintf(serviceFile, MAXPGPATH, "%s/pg_service.conf",
|
2005-06-12 02:00:21 +02:00
|
|
|
getenv("PGSYSCONFDIR") ? getenv("PGSYSCONFDIR") : SYSCONFDIR);
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
if (stat(serviceFile, &stat_buf) != 0)
|
2010-01-20 22:15:21 +01:00
|
|
|
goto last_file;
|
|
|
|
|
|
|
|
status = parseServiceFile(serviceFile, service, options, errorMessage, &group_found);
|
|
|
|
if (status != 0)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
last_file:
|
|
|
|
if (!group_found)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("definition of service \"%s\" not found\n"), service);
|
2010-01-20 22:15:21 +01:00
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
parseServiceFile(const char *serviceFile,
|
|
|
|
const char *service,
|
|
|
|
PQconninfoOption *options,
|
|
|
|
PQExpBuffer errorMessage,
|
|
|
|
bool *group_found)
|
2010-02-26 03:01:40 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
int linenr = 0,
|
|
|
|
i;
|
|
|
|
FILE *f;
|
|
|
|
char buf[MAXBUFSIZE],
|
|
|
|
*line;
|
2004-06-03 02:07:38 +02:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
f = fopen(serviceFile, "r");
|
|
|
|
if (f == NULL)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("service file \"%s\" not found\n"),
|
|
|
|
serviceFile);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((line = fgets(buf, sizeof(buf), f)) != NULL)
|
|
|
|
{
|
|
|
|
linenr++;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
if (strlen(line) >= sizeof(buf) - 1)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
fclose(f);
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("line %d too long in service file \"%s\"\n"),
|
2010-01-20 22:15:21 +01:00
|
|
|
linenr,
|
2001-03-22 05:01:46 +01:00
|
|
|
serviceFile);
|
2010-01-20 22:15:21 +01:00
|
|
|
return 2;
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/* ignore EOL at end of line */
|
|
|
|
if (strlen(line) && line[strlen(line) - 1] == '\n')
|
|
|
|
line[strlen(line) - 1] = 0;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/* ignore leading blanks */
|
|
|
|
while (*line && isspace((unsigned char) line[0]))
|
|
|
|
line++;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/* ignore comments and empty lines */
|
|
|
|
if (strlen(line) == 0 || line[0] == '#')
|
|
|
|
continue;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/* Check for right groupname */
|
|
|
|
if (line[0] == '[')
|
|
|
|
{
|
|
|
|
if (*group_found)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
/* group info already read */
|
|
|
|
fclose(f);
|
|
|
|
return 0;
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
2010-01-20 22:15:21 +01:00
|
|
|
|
|
|
|
if (strncmp(line + 1, service, strlen(service)) == 0 &&
|
|
|
|
line[strlen(service) + 1] == ']')
|
|
|
|
*group_found = true;
|
2001-03-22 05:01:46 +01:00
|
|
|
else
|
2010-01-20 22:15:21 +01:00
|
|
|
*group_found = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (*group_found)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Finally, we are in the right group and can parse the line
|
2010-01-20 22:15:21 +01:00
|
|
|
*/
|
|
|
|
char *key,
|
|
|
|
*val;
|
|
|
|
bool found_keyword;
|
2000-10-17 03:00:58 +02:00
|
|
|
|
2006-07-27 15:20:24 +02:00
|
|
|
#ifdef USE_LDAP
|
2010-01-20 22:15:21 +01:00
|
|
|
if (strncmp(line, "ldap", 4) == 0)
|
|
|
|
{
|
|
|
|
int rc = ldapServiceLookup(line, options, errorMessage);
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/* if rc = 2, go on reading for fallback */
|
|
|
|
switch (rc)
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
fclose(f);
|
|
|
|
return 0;
|
|
|
|
case 1:
|
|
|
|
case 3:
|
|
|
|
fclose(f);
|
|
|
|
return 3;
|
|
|
|
case 2:
|
|
|
|
continue;
|
2006-07-27 15:20:24 +02:00
|
|
|
}
|
2010-01-20 22:15:21 +01:00
|
|
|
}
|
2006-07-27 15:20:24 +02:00
|
|
|
#endif
|
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
key = line;
|
|
|
|
val = strchr(line, '=');
|
|
|
|
if (val == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("syntax error in service file \"%s\", line %d\n"),
|
|
|
|
serviceFile,
|
|
|
|
linenr);
|
|
|
|
fclose(f);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
*val++ = '\0';
|
2003-01-08 17:21:53 +01:00
|
|
|
|
2015-04-08 16:26:21 +02:00
|
|
|
if (strcmp(key, "service") == 0)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("nested service specifications not supported in service file \"%s\", line %d\n"),
|
|
|
|
serviceFile,
|
|
|
|
linenr);
|
|
|
|
fclose(f);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
/*
|
|
|
|
* Set the parameter --- but don't override any previous
|
|
|
|
* explicit setting.
|
|
|
|
*/
|
|
|
|
found_keyword = false;
|
|
|
|
for (i = 0; options[i].keyword; i++)
|
|
|
|
{
|
|
|
|
if (strcmp(options[i].keyword, key) == 0)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2010-01-20 22:15:21 +01:00
|
|
|
if (options[i].val == NULL)
|
|
|
|
options[i].val = strdup(val);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!options[i].val)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("out of memory\n"));
|
2014-11-25 11:55:00 +01:00
|
|
|
fclose(f);
|
|
|
|
return 3;
|
|
|
|
}
|
2010-01-20 22:15:21 +01:00
|
|
|
found_keyword = true;
|
|
|
|
break;
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
2010-01-20 22:15:21 +01:00
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
if (!found_keyword)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("syntax error in service file \"%s\", line %d\n"),
|
|
|
|
serviceFile,
|
|
|
|
linenr);
|
|
|
|
fclose(f);
|
|
|
|
return 3;
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-20 22:15:21 +01:00
|
|
|
fclose(f);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
return 0;
|
2000-10-17 03:00:58 +02:00
|
|
|
}
|
|
|
|
|
1998-01-26 02:42:53 +01:00
|
|
|
|
2008-09-22 15:55:14 +02:00
|
|
|
/*
|
|
|
|
* PQconninfoParse
|
|
|
|
*
|
|
|
|
* Parse a string like PQconnectdb() would do and return the
|
2014-05-06 18:12:18 +02:00
|
|
|
* resulting connection options array. NULL is returned on failure.
|
2008-09-22 15:55:14 +02:00
|
|
|
* The result contains only options specified directly in the string,
|
|
|
|
* not any possible default values.
|
|
|
|
*
|
|
|
|
* If errmsg isn't NULL, *errmsg is set to NULL on success, or a malloc'd
|
|
|
|
* string on failure (use PQfreemem to free it). In out-of-memory conditions
|
|
|
|
* both *errmsg and the result could be NULL.
|
|
|
|
*
|
|
|
|
* NOTE: the returned array is dynamically allocated and should
|
|
|
|
* be freed when no longer needed via PQconninfoFree().
|
|
|
|
*/
|
|
|
|
PQconninfoOption *
|
|
|
|
PQconninfoParse(const char *conninfo, char **errmsg)
|
|
|
|
{
|
|
|
|
PQExpBufferData errorBuf;
|
|
|
|
PQconninfoOption *connOptions;
|
|
|
|
|
|
|
|
if (errmsg)
|
|
|
|
*errmsg = NULL; /* default */
|
|
|
|
initPQExpBuffer(&errorBuf);
|
2011-10-19 03:44:23 +02:00
|
|
|
if (PQExpBufferDataBroken(errorBuf))
|
2008-09-22 15:55:14 +02:00
|
|
|
return NULL; /* out of memory already :-( */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
connOptions = parse_connection_string(conninfo, &errorBuf, false);
|
2008-09-22 15:55:14 +02:00
|
|
|
if (connOptions == NULL && errmsg)
|
|
|
|
*errmsg = errorBuf.data;
|
|
|
|
else
|
|
|
|
termPQExpBuffer(&errorBuf);
|
|
|
|
return connOptions;
|
|
|
|
}
|
|
|
|
|
2012-03-22 17:08:34 +01:00
|
|
|
/*
|
|
|
|
* Build a working copy of the constant PQconninfoOptions array.
|
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
|
|
|
conninfo_init(PQExpBuffer errorMessage)
|
|
|
|
{
|
|
|
|
PQconninfoOption *options;
|
2012-11-30 07:09:18 +01:00
|
|
|
PQconninfoOption *opt_dest;
|
|
|
|
const internalPQconninfoOption *cur_opt;
|
2012-03-22 17:08:34 +01:00
|
|
|
|
2012-11-30 07:09:18 +01:00
|
|
|
/*
|
|
|
|
* Get enough memory for all options in PQconninfoOptions, even if some
|
|
|
|
* end up being filtered out.
|
|
|
|
*/
|
|
|
|
options = (PQconninfoOption *) malloc(sizeof(PQconninfoOption) * sizeof(PQconninfoOptions) / sizeof(PQconninfoOptions[0]));
|
2012-03-22 17:08:34 +01:00
|
|
|
if (options == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return NULL;
|
|
|
|
}
|
2012-11-30 07:09:18 +01:00
|
|
|
opt_dest = options;
|
|
|
|
|
|
|
|
for (cur_opt = PQconninfoOptions; cur_opt->keyword; cur_opt++)
|
|
|
|
{
|
|
|
|
/* Only copy the public part of the struct, not the full internal */
|
|
|
|
memcpy(opt_dest, cur_opt, sizeof(PQconninfoOption));
|
|
|
|
opt_dest++;
|
|
|
|
}
|
|
|
|
MemSet(opt_dest, 0, sizeof(PQconninfoOption));
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2012-03-22 17:08:34 +01:00
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
2001-08-17 17:11:15 +02:00
|
|
|
/*
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* Connection string parser
|
2000-03-11 04:08:37 +01:00
|
|
|
*
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* Returns a malloc'd PQconninfoOption array, if parsing is successful.
|
|
|
|
* Otherwise, NULL is returned and an error message is left in errorMessage.
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* If use_defaults is true, default values are filled in (from a service file,
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* environment variables, etc).
|
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
|
|
|
parse_connection_string(const char *connstr, PQExpBuffer errorMessage,
|
|
|
|
bool use_defaults)
|
|
|
|
{
|
|
|
|
/* Parse as URI if connection string matches URI prefix */
|
2015-04-02 16:10:22 +02:00
|
|
|
if (uri_prefix_length(connstr) != 0)
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
return conninfo_uri_parse(connstr, errorMessage, use_defaults);
|
|
|
|
|
|
|
|
/* Parse as default otherwise */
|
|
|
|
return conninfo_parse(connstr, errorMessage, use_defaults);
|
|
|
|
}
|
|
|
|
|
2015-04-02 16:10:22 +02:00
|
|
|
/*
|
|
|
|
* Checks if connection string starts with either of the valid URI prefix
|
|
|
|
* designators.
|
|
|
|
*
|
|
|
|
* Returns the URI prefix length, 0 if the string doesn't contain a URI prefix.
|
psql: fix \connect with URIs and conninfo strings
This is the second try at this, after fcef1617295 failed miserably and
had to be reverted: as it turns out, libpq cannot depend on libpgcommon
after all. Instead of shuffling code in the master branch, make that one
just like 9.4 and accept the duplication. (This was all my own mistake,
not the patch submitter's).
psql was already accepting conninfo strings as the first parameter in
\connect, but the way it worked wasn't sane; some of the other
parameters would get the previous connection's values, causing it to
connect to a completely unexpected server or, more likely, not finding
any server at all because of completely wrong combinations of
parameters.
Fix by explicitely checking for a conninfo-looking parameter in the
dbname position; if one is found, use its complete specification rather
than mix with the other arguments. Also, change tab-completion to not
try to complete conninfo/URI-looking "dbnames" and document that
conninfos are accepted as first argument.
There was a weak consensus to backpatch this, because while the behavior
of using the dbname as a conninfo is nowhere documented for \connect, it
is reasonable to expect that it works because it does work in many other
contexts. Therefore this is backpatched all the way back to 9.0.
Author: David Fetter, Andrew Dunstan. Some editorialization by me
(probably earning a Gierth's "Sloppy" badge in the process.)
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,
Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
|
|
|
*
|
|
|
|
* XXX this is duplicated in psql/common.c.
|
2015-04-02 16:10:22 +02:00
|
|
|
*/
|
|
|
|
static int
|
|
|
|
uri_prefix_length(const char *connstr)
|
|
|
|
{
|
|
|
|
if (strncmp(connstr, uri_designator,
|
|
|
|
sizeof(uri_designator) - 1) == 0)
|
|
|
|
return sizeof(uri_designator) - 1;
|
|
|
|
|
|
|
|
if (strncmp(connstr, short_uri_designator,
|
|
|
|
sizeof(short_uri_designator) - 1) == 0)
|
|
|
|
return sizeof(short_uri_designator) - 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recognized connection string either starts with a valid URI prefix or
|
|
|
|
* contains a "=" in it.
|
|
|
|
*
|
|
|
|
* Must be consistent with parse_connection_string: anything for which this
|
|
|
|
* returns true should at least look like it's parseable by that routine.
|
psql: fix \connect with URIs and conninfo strings
This is the second try at this, after fcef1617295 failed miserably and
had to be reverted: as it turns out, libpq cannot depend on libpgcommon
after all. Instead of shuffling code in the master branch, make that one
just like 9.4 and accept the duplication. (This was all my own mistake,
not the patch submitter's).
psql was already accepting conninfo strings as the first parameter in
\connect, but the way it worked wasn't sane; some of the other
parameters would get the previous connection's values, causing it to
connect to a completely unexpected server or, more likely, not finding
any server at all because of completely wrong combinations of
parameters.
Fix by explicitely checking for a conninfo-looking parameter in the
dbname position; if one is found, use its complete specification rather
than mix with the other arguments. Also, change tab-completion to not
try to complete conninfo/URI-looking "dbnames" and document that
conninfos are accepted as first argument.
There was a weak consensus to backpatch this, because while the behavior
of using the dbname as a conninfo is nowhere documented for \connect, it
is reasonable to expect that it works because it does work in many other
contexts. Therefore this is backpatched all the way back to 9.0.
Author: David Fetter, Andrew Dunstan. Some editorialization by me
(probably earning a Gierth's "Sloppy" badge in the process.)
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,
Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
|
|
|
*
|
|
|
|
* XXX this is duplicated in psql/common.c
|
2015-04-02 16:10:22 +02:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
recognized_connection_string(const char *connstr)
|
|
|
|
{
|
|
|
|
return uri_prefix_length(connstr) != 0 || strchr(connstr, '=') != NULL;
|
|
|
|
}
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/*
|
|
|
|
* Subroutine for parse_connection_string
|
|
|
|
*
|
|
|
|
* Deal with a string containing key=value pairs.
|
1996-11-09 11:39:54 +01:00
|
|
|
*/
|
2000-03-11 04:08:37 +01:00
|
|
|
static PQconninfoOption *
|
2007-12-09 20:01:40 +01:00
|
|
|
conninfo_parse(const char *conninfo, PQExpBuffer errorMessage,
|
2008-09-22 16:21:44 +02:00
|
|
|
bool use_defaults)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
char *pname;
|
|
|
|
char *pval;
|
|
|
|
char *buf;
|
|
|
|
char *cp;
|
|
|
|
char *cp2;
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoOption *options;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
/* Make a working copy of PQconninfoOptions */
|
2012-03-22 17:08:34 +01:00
|
|
|
options = conninfo_init(errorMessage);
|
2000-03-11 04:08:37 +01:00
|
|
|
if (options == NULL)
|
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
/* Need a modifiable copy of the input string */
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((buf = strdup(conninfo)) == NULL)
|
|
|
|
{
|
1999-08-31 03:37:37 +02:00
|
|
|
printfPQExpBuffer(errorMessage,
|
2001-07-15 15:45:04 +02:00
|
|
|
libpq_gettext("out of memory\n"));
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoFree(options);
|
|
|
|
return NULL;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
cp = buf;
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
while (*cp)
|
|
|
|
{
|
|
|
|
/* Skip blanks before the parameter name */
|
2000-12-03 21:45:40 +01:00
|
|
|
if (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
cp++;
|
|
|
|
continue;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* Get the parameter name */
|
|
|
|
pname = cp;
|
|
|
|
while (*cp)
|
|
|
|
{
|
|
|
|
if (*cp == '=')
|
|
|
|
break;
|
2000-12-03 21:45:40 +01:00
|
|
|
if (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
*cp++ = '\0';
|
|
|
|
while (*cp)
|
|
|
|
{
|
2000-12-03 21:45:40 +01:00
|
|
|
if (!isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
cp++;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cp++;
|
|
|
|
}
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* Check that there is a following '=' */
|
|
|
|
if (*cp != '=')
|
|
|
|
{
|
1999-08-31 03:37:37 +02:00
|
|
|
printfPQExpBuffer(errorMessage,
|
2001-07-15 15:45:04 +02:00
|
|
|
libpq_gettext("missing \"=\" after \"%s\" in connection info string\n"),
|
1999-08-31 03:37:37 +02:00
|
|
|
pname);
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoFree(options);
|
1997-09-07 07:04:48 +02:00
|
|
|
free(buf);
|
2000-03-11 04:08:37 +01:00
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
*cp++ = '\0';
|
1996-11-09 11:39:54 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* Skip blanks after the '=' */
|
|
|
|
while (*cp)
|
|
|
|
{
|
2000-12-03 21:45:40 +01:00
|
|
|
if (!isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
cp++;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
/* Get the parameter value */
|
1997-09-07 07:04:48 +02:00
|
|
|
pval = cp;
|
|
|
|
|
|
|
|
if (*cp != '\'')
|
|
|
|
{
|
|
|
|
cp2 = pval;
|
|
|
|
while (*cp)
|
|
|
|
{
|
2000-12-03 21:45:40 +01:00
|
|
|
if (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
*cp++ = '\0';
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (*cp == '\\')
|
|
|
|
{
|
|
|
|
cp++;
|
|
|
|
if (*cp != '\0')
|
|
|
|
*cp2++ = *cp++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
*cp2++ = *cp++;
|
|
|
|
}
|
|
|
|
*cp2 = '\0';
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
cp2 = pval;
|
|
|
|
cp++;
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
if (*cp == '\0')
|
|
|
|
{
|
1999-08-31 03:37:37 +02:00
|
|
|
printfPQExpBuffer(errorMessage,
|
2001-07-15 15:45:04 +02:00
|
|
|
libpq_gettext("unterminated quoted string in connection info string\n"));
|
2000-03-11 04:08:37 +01:00
|
|
|
PQconninfoFree(options);
|
1997-09-07 07:04:48 +02:00
|
|
|
free(buf);
|
2000-03-11 04:08:37 +01:00
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
if (*cp == '\\')
|
|
|
|
{
|
|
|
|
cp++;
|
|
|
|
if (*cp != '\0')
|
|
|
|
*cp2++ = *cp++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (*cp == '\'')
|
|
|
|
{
|
|
|
|
*cp2 = '\0';
|
|
|
|
cp++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
*cp2++ = *cp++;
|
|
|
|
}
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* Now that we have the name and the value, store the record.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (!conninfo_storeval(options, pname, pval, errorMessage, false, false))
|
2005-06-12 02:00:21 +02:00
|
|
|
{
|
|
|
|
PQconninfoFree(options);
|
|
|
|
free(buf);
|
|
|
|
return NULL;
|
|
|
|
}
|
2000-10-17 03:00:58 +02:00
|
|
|
}
|
|
|
|
|
2003-04-28 06:29:12 +02:00
|
|
|
/* Done with the modifiable input string */
|
|
|
|
free(buf);
|
|
|
|
|
2008-09-22 15:55:14 +02:00
|
|
|
/*
|
2012-03-22 17:08:34 +01:00
|
|
|
* Add in defaults if the caller wants that.
|
1996-11-09 11:39:54 +01:00
|
|
|
*/
|
2012-03-22 17:08:34 +01:00
|
|
|
if (use_defaults)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2012-03-22 17:08:34 +01:00
|
|
|
if (!conninfo_add_defaults(options, errorMessage))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2012-03-22 17:08:34 +01:00
|
|
|
PQconninfoFree(options);
|
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
return options;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
2010-01-28 07:28:26 +01:00
|
|
|
/*
|
|
|
|
* Conninfo array parser routine
|
|
|
|
*
|
|
|
|
* If successful, a malloc'd PQconninfoOption array is returned.
|
|
|
|
* If not successful, NULL is returned and an error message is
|
|
|
|
* left in errorMessage.
|
|
|
|
* Defaults are supplied (from a service file, environment variables, etc)
|
2017-08-16 06:22:32 +02:00
|
|
|
* for unspecified options, but only if use_defaults is true.
|
2010-02-05 04:09:05 +01:00
|
|
|
*
|
2014-11-25 16:12:07 +01:00
|
|
|
* If expand_dbname is non-zero, and the value passed for the first occurrence
|
|
|
|
* of "dbname" keyword is a connection string (as indicated by
|
2015-04-02 16:10:22 +02:00
|
|
|
* recognized_connection_string) then parse and process it, overriding any
|
2014-11-25 16:12:07 +01:00
|
|
|
* previously processed conflicting keywords. Subsequent keywords will take
|
2016-08-08 16:07:46 +02:00
|
|
|
* precedence, however. In-tree programs generally specify expand_dbname=true,
|
|
|
|
* so command-line arguments naming a database can use a connection string.
|
|
|
|
* Some code acquires arbitrary database names from known-literal sources like
|
|
|
|
* PQdb(), PQconninfoParse() and pg_database.datname. When connecting to such
|
|
|
|
* a database, in-tree code first wraps the name in a connection string.
|
2010-01-28 07:28:26 +01:00
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
2017-06-21 20:39:04 +02:00
|
|
|
conninfo_array_parse(const char *const *keywords, const char *const *values,
|
2010-02-05 04:09:05 +01:00
|
|
|
PQExpBuffer errorMessage, bool use_defaults,
|
|
|
|
int expand_dbname)
|
2010-01-28 07:28:26 +01:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
PQconninfoOption *options;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
PQconninfoOption *dbname_options = NULL;
|
2010-02-26 03:01:40 +01:00
|
|
|
PQconninfoOption *option;
|
|
|
|
int i = 0;
|
2010-01-28 07:28:26 +01:00
|
|
|
|
2010-02-05 04:09:05 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* If expand_dbname is non-zero, check keyword "dbname" to see if val is
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* actually a recognized connection string.
|
2010-02-05 04:09:05 +01:00
|
|
|
*/
|
2010-02-26 03:01:40 +01:00
|
|
|
while (expand_dbname && keywords[i])
|
2010-02-05 04:09:05 +01:00
|
|
|
{
|
|
|
|
const char *pname = keywords[i];
|
2010-02-26 03:01:40 +01:00
|
|
|
const char *pvalue = values[i];
|
2010-02-05 04:09:05 +01:00
|
|
|
|
|
|
|
/* first find "dbname" if any */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (strcmp(pname, "dbname") == 0 && pvalue)
|
2010-02-05 04:09:05 +01:00
|
|
|
{
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* If value is a connection string, parse it, but do not use
|
|
|
|
* defaults here -- those get picked up later. We only want to
|
|
|
|
* override for those parameters actually passed.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
2015-04-02 16:10:22 +02:00
|
|
|
if (recognized_connection_string(pvalue))
|
2010-02-05 04:09:05 +01:00
|
|
|
{
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
dbname_options = parse_connection_string(pvalue, errorMessage, false);
|
|
|
|
if (dbname_options == NULL)
|
2010-02-05 04:09:05 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
++i;
|
|
|
|
}
|
|
|
|
|
2010-01-28 07:28:26 +01:00
|
|
|
/* Make a working copy of PQconninfoOptions */
|
2012-03-22 17:08:34 +01:00
|
|
|
options = conninfo_init(errorMessage);
|
2010-01-28 07:28:26 +01:00
|
|
|
if (options == NULL)
|
|
|
|
{
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
PQconninfoFree(dbname_options);
|
2010-01-28 07:28:26 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse the keywords/values arrays */
|
2012-03-22 17:08:34 +01:00
|
|
|
i = 0;
|
2010-02-26 03:01:40 +01:00
|
|
|
while (keywords[i])
|
2010-01-28 07:28:26 +01:00
|
|
|
{
|
|
|
|
const char *pname = keywords[i];
|
2010-02-26 03:01:40 +01:00
|
|
|
const char *pvalue = values[i];
|
2010-01-28 07:28:26 +01:00
|
|
|
|
2014-04-19 14:41:51 +02:00
|
|
|
if (pvalue != NULL && pvalue[0] != '\0')
|
2010-01-28 07:28:26 +01:00
|
|
|
{
|
|
|
|
/* Search for the param record */
|
|
|
|
for (option = options; option->keyword != NULL; option++)
|
|
|
|
{
|
|
|
|
if (strcmp(option->keyword, pname) == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for invalid connection option */
|
|
|
|
if (option->keyword == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid connection option \"%s\"\n"),
|
2010-01-28 07:28:26 +01:00
|
|
|
pname);
|
|
|
|
PQconninfoFree(options);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
PQconninfoFree(dbname_options);
|
2010-01-28 07:28:26 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-02-05 04:09:05 +01:00
|
|
|
/*
|
2014-11-25 16:12:07 +01:00
|
|
|
* If we are on the first dbname parameter, and we have a parsed
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
* connection string, copy those parameters across, overriding any
|
|
|
|
* existing previous settings.
|
2010-02-05 04:09:05 +01:00
|
|
|
*/
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (strcmp(pname, "dbname") == 0 && dbname_options)
|
2010-02-05 04:09:05 +01:00
|
|
|
{
|
|
|
|
PQconninfoOption *str_option;
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
for (str_option = dbname_options; str_option->keyword != NULL; str_option++)
|
2010-02-05 04:09:05 +01:00
|
|
|
{
|
|
|
|
if (str_option->val != NULL)
|
|
|
|
{
|
|
|
|
int k;
|
|
|
|
|
|
|
|
for (k = 0; options[k].keyword; k++)
|
|
|
|
{
|
|
|
|
if (strcmp(options[k].keyword, str_option->keyword) == 0)
|
|
|
|
{
|
|
|
|
if (options[k].val)
|
|
|
|
free(options[k].val);
|
|
|
|
options[k].val = strdup(str_option->val);
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!options[k].val)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("out of memory\n"));
|
2014-11-25 11:55:00 +01:00
|
|
|
PQconninfoFree(options);
|
|
|
|
PQconninfoFree(dbname_options);
|
|
|
|
return NULL;
|
|
|
|
}
|
2010-02-05 04:09:05 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-24 03:35:49 +02:00
|
|
|
|
2014-11-25 16:12:07 +01:00
|
|
|
/*
|
|
|
|
* Forget the parsed connection string, so that any subsequent
|
|
|
|
* dbname parameters will not be expanded.
|
|
|
|
*/
|
|
|
|
PQconninfoFree(dbname_options);
|
|
|
|
dbname_options = NULL;
|
2010-02-05 04:09:05 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Store the value, overriding previous settings
|
|
|
|
*/
|
|
|
|
if (option->val)
|
|
|
|
free(option->val);
|
|
|
|
option->val = strdup(pvalue);
|
|
|
|
if (!option->val)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
PQconninfoFree(options);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
PQconninfoFree(dbname_options);
|
2010-02-05 04:09:05 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
|
|
|
++i;
|
|
|
|
}
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
PQconninfoFree(dbname_options);
|
2010-01-28 07:28:26 +01:00
|
|
|
|
|
|
|
/*
|
2012-03-22 17:08:34 +01:00
|
|
|
* Add in defaults if the caller wants that.
|
2010-01-28 07:28:26 +01:00
|
|
|
*/
|
2012-03-22 17:08:34 +01:00
|
|
|
if (use_defaults)
|
|
|
|
{
|
|
|
|
if (!conninfo_add_defaults(options, errorMessage))
|
|
|
|
{
|
|
|
|
PQconninfoFree(options);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add the default values for any unspecified options to the connection
|
|
|
|
* options array.
|
|
|
|
*
|
|
|
|
* Defaults are obtained from a service file, environment variables, etc.
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* Returns true if successful, otherwise false; errorMessage, if supplied,
|
2013-12-03 17:11:56 +01:00
|
|
|
* is filled in upon failure. Note that failure to locate a default value
|
|
|
|
* is not an error condition here --- we just leave the option's value as
|
|
|
|
* NULL.
|
2012-03-22 17:08:34 +01:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
conninfo_add_defaults(PQconninfoOption *options, PQExpBuffer errorMessage)
|
|
|
|
{
|
|
|
|
PQconninfoOption *option;
|
|
|
|
char *tmp;
|
2010-01-28 07:28:26 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If there's a service spec, use it to obtain any not-explicitly-given
|
2014-05-06 18:12:18 +02:00
|
|
|
* parameters. Ignore error if no error message buffer is passed because
|
|
|
|
* there is no way to pass back the failure message.
|
2010-01-28 07:28:26 +01:00
|
|
|
*/
|
2013-12-03 17:11:56 +01:00
|
|
|
if (parseServiceInfo(options, errorMessage) != 0 && errorMessage)
|
2012-03-22 17:08:34 +01:00
|
|
|
return false;
|
2010-01-28 07:28:26 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the fallback resources for parameters not specified in the conninfo
|
|
|
|
* string nor the service.
|
|
|
|
*/
|
|
|
|
for (option = options; option->keyword != NULL; option++)
|
|
|
|
{
|
|
|
|
if (option->val != NULL)
|
|
|
|
continue; /* Value was in conninfo or service */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to get the environment variable fallback
|
|
|
|
*/
|
|
|
|
if (option->envvar != NULL)
|
|
|
|
{
|
|
|
|
if ((tmp = getenv(option->envvar)) != NULL)
|
|
|
|
{
|
|
|
|
option->val = strdup(tmp);
|
|
|
|
if (!option->val)
|
|
|
|
{
|
2013-12-03 17:11:56 +01:00
|
|
|
if (errorMessage)
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
2012-03-22 17:08:34 +01:00
|
|
|
return false;
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-08 16:24:24 +02:00
|
|
|
/*
|
|
|
|
* Interpret the deprecated PGREQUIRESSL environment variable. Per
|
|
|
|
* tradition, translate values starting with "1" to sslmode=require,
|
|
|
|
* and ignore other values. Given both PGREQUIRESSL=1 and PGSSLMODE,
|
|
|
|
* PGSSLMODE takes precedence; the opposite was true before v9.3.
|
|
|
|
*/
|
|
|
|
if (strcmp(option->keyword, "sslmode") == 0)
|
|
|
|
{
|
|
|
|
const char *requiresslenv = getenv("PGREQUIRESSL");
|
|
|
|
|
|
|
|
if (requiresslenv != NULL && requiresslenv[0] == '1')
|
|
|
|
{
|
|
|
|
option->val = strdup("require");
|
|
|
|
if (!option->val)
|
|
|
|
{
|
|
|
|
if (errorMessage)
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-28 07:28:26 +01:00
|
|
|
/*
|
2012-03-22 17:08:34 +01:00
|
|
|
* No environment variable specified or the variable isn't set - try
|
|
|
|
* compiled-in default
|
2010-01-28 07:28:26 +01:00
|
|
|
*/
|
|
|
|
if (option->compiled != NULL)
|
|
|
|
{
|
|
|
|
option->val = strdup(option->compiled);
|
|
|
|
if (!option->val)
|
|
|
|
{
|
2013-12-03 17:11:56 +01:00
|
|
|
if (errorMessage)
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
2012-03-22 17:08:34 +01:00
|
|
|
return false;
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
* Special handling for "user" option. Note that if pg_fe_getauthname
|
|
|
|
* fails, we just leave the value as NULL; there's no need for this to
|
|
|
|
* be an error condition if the caller provides a user name. The only
|
|
|
|
* reason we do this now at all is so that callers of PQconndefaults
|
|
|
|
* will see a correct default (barring error, of course).
|
2010-01-28 07:28:26 +01:00
|
|
|
*/
|
|
|
|
if (strcmp(option->keyword, "user") == 0)
|
|
|
|
{
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
option->val = pg_fe_getauthname(NULL);
|
2010-01-28 07:28:26 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-22 17:08:34 +01:00
|
|
|
return true;
|
2010-01-28 07:28:26 +01:00
|
|
|
}
|
1996-11-09 11:39:54 +01:00
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/*
|
|
|
|
* Subroutine for parse_connection_string
|
|
|
|
*
|
|
|
|
* Deal with a URI connection string.
|
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
|
|
|
conninfo_uri_parse(const char *uri, PQExpBuffer errorMessage,
|
|
|
|
bool use_defaults)
|
|
|
|
{
|
|
|
|
PQconninfoOption *options;
|
|
|
|
|
|
|
|
/* Make a working copy of PQconninfoOptions */
|
|
|
|
options = conninfo_init(errorMessage);
|
|
|
|
if (options == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (!conninfo_uri_parse_options(options, uri, errorMessage))
|
|
|
|
{
|
|
|
|
PQconninfoFree(options);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add in defaults if the caller wants that.
|
|
|
|
*/
|
|
|
|
if (use_defaults)
|
|
|
|
{
|
|
|
|
if (!conninfo_add_defaults(options, errorMessage))
|
|
|
|
{
|
|
|
|
PQconninfoFree(options);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* conninfo_uri_parse_options
|
|
|
|
* Actual URI parser.
|
|
|
|
*
|
|
|
|
* If successful, returns true while the options array is filled with parsed
|
|
|
|
* options from the URI.
|
|
|
|
* If not successful, returns false and fills errorMessage accordingly.
|
|
|
|
*
|
2012-05-28 21:44:34 +02:00
|
|
|
* Parses the connection URI string in 'uri' according to the URI syntax (RFC
|
|
|
|
* 3986):
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*
|
2012-05-28 21:44:34 +02:00
|
|
|
* postgresql://[user[:password]@][netloc][:port][/dbname][?param1=value1&...]
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*
|
2012-05-28 21:44:34 +02:00
|
|
|
* where "netloc" is a hostname, an IPv4 address, or an IPv6 address surrounded
|
2016-11-03 14:25:20 +01:00
|
|
|
* by literal square brackets. As an extension, we also allow multiple
|
|
|
|
* netloc[:port] specifications, separated by commas:
|
|
|
|
*
|
|
|
|
* postgresql://[user[:password]@][netloc][:port][,...][/dbname][?param1=value1&...]
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*
|
2012-05-28 21:44:34 +02:00
|
|
|
* Any of the URI parts might use percent-encoding (%xy).
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
conninfo_uri_parse_options(PQconninfoOption *options, const char *uri,
|
|
|
|
PQExpBuffer errorMessage)
|
|
|
|
{
|
2012-06-10 21:20:04 +02:00
|
|
|
int prefix_len;
|
|
|
|
char *p;
|
2016-11-22 21:32:13 +01:00
|
|
|
char *buf = NULL;
|
2014-11-25 11:55:00 +01:00
|
|
|
char *start;
|
2012-06-10 21:20:04 +02:00
|
|
|
char prevchar = '\0';
|
|
|
|
char *user = NULL;
|
|
|
|
char *host = NULL;
|
|
|
|
bool retval = false;
|
2017-05-17 22:31:56 +02:00
|
|
|
PQExpBufferData hostbuf;
|
|
|
|
PQExpBufferData portbuf;
|
2016-11-03 14:25:20 +01:00
|
|
|
|
|
|
|
initPQExpBuffer(&hostbuf);
|
|
|
|
initPQExpBuffer(&portbuf);
|
|
|
|
if (PQExpBufferDataBroken(hostbuf) || PQExpBufferDataBroken(portbuf))
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
2016-11-22 21:32:13 +01:00
|
|
|
goto cleanup;
|
2016-11-03 14:25:20 +01:00
|
|
|
}
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2014-11-25 11:55:00 +01:00
|
|
|
/* need a modifiable copy of the input URI */
|
|
|
|
buf = strdup(uri);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (buf == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("out of memory\n"));
|
2016-11-22 21:32:13 +01:00
|
|
|
goto cleanup;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
2014-11-25 11:55:00 +01:00
|
|
|
start = buf;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
/* Skip the URI prefix */
|
2015-04-02 16:10:22 +02:00
|
|
|
prefix_len = uri_prefix_length(uri);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (prefix_len == 0)
|
|
|
|
{
|
|
|
|
/* Should never happen */
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("invalid URI propagated to internal parser routine: \"%s\"\n"),
|
|
|
|
uri);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
start += prefix_len;
|
|
|
|
p = start;
|
|
|
|
|
|
|
|
/* Look ahead for possible user credentials designator */
|
|
|
|
while (*p && *p != '@' && *p != '/')
|
|
|
|
++p;
|
|
|
|
if (*p == '@')
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Found username/password designator, so URI should be of the form
|
|
|
|
* "scheme://user[:password]@[netloc]".
|
|
|
|
*/
|
|
|
|
user = start;
|
|
|
|
|
|
|
|
p = user;
|
|
|
|
while (*p != ':' && *p != '@')
|
|
|
|
++p;
|
|
|
|
|
|
|
|
/* Save last char and cut off at end of user name */
|
|
|
|
prevchar = *p;
|
|
|
|
*p = '\0';
|
|
|
|
|
2012-05-28 21:44:34 +02:00
|
|
|
if (*user &&
|
|
|
|
!conninfo_storeval(options, "user", user,
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
errorMessage, false, true))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
if (prevchar == ':')
|
|
|
|
{
|
|
|
|
const char *password = p + 1;
|
|
|
|
|
|
|
|
while (*p != '@')
|
|
|
|
++p;
|
|
|
|
*p = '\0';
|
|
|
|
|
2012-05-28 21:44:34 +02:00
|
|
|
if (*password &&
|
|
|
|
!conninfo_storeval(options, "password", password,
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
errorMessage, false, true))
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Advance past end of parsed user name or password token */
|
|
|
|
++p;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* No username/password designator found. Reset to start of URI.
|
|
|
|
*/
|
|
|
|
p = start;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2016-11-03 14:25:20 +01:00
|
|
|
* There may be multiple netloc[:port] pairs, each separated from the next
|
|
|
|
* by a comma. When we initially enter this loop, "p" has been
|
|
|
|
* incremented past optional URI credential information at this point and
|
|
|
|
* now points at the "netloc" part of the URI. On subsequent loop
|
|
|
|
* iterations, "p" has been incremented past the comma separator and now
|
|
|
|
* points at the start of the next "netloc".
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
for (;;)
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
{
|
2012-05-28 21:44:34 +02:00
|
|
|
/*
|
2016-11-03 14:25:20 +01:00
|
|
|
* Look for IPv6 address.
|
2012-05-28 21:44:34 +02:00
|
|
|
*/
|
2016-11-03 14:25:20 +01:00
|
|
|
if (*p == '[')
|
2012-05-28 21:44:34 +02:00
|
|
|
{
|
2016-11-03 14:25:20 +01:00
|
|
|
host = ++p;
|
|
|
|
while (*p && *p != ']')
|
|
|
|
++p;
|
|
|
|
if (!*p)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("end of string reached when looking for matching \"]\" in IPv6 host address in URI: \"%s\"\n"),
|
|
|
|
uri);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
if (p == host)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("IPv6 host address may not be empty in URI: \"%s\"\n"),
|
|
|
|
uri);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Cut off the bracket and advance */
|
|
|
|
*(p++) = '\0';
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The address may be followed by a port specifier or a slash or a
|
|
|
|
* query or a separator comma.
|
|
|
|
*/
|
|
|
|
if (*p && *p != ':' && *p != '/' && *p != '?' && *p != ',')
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
|
|
|
libpq_gettext("unexpected character \"%c\" at position %d in URI (expected \":\" or \"/\"): \"%s\"\n"),
|
|
|
|
*p, (int) (p - buf + 1), uri);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2012-05-28 21:44:34 +02:00
|
|
|
}
|
2016-11-03 14:25:20 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* not an IPv6 address: DNS-named or IPv4 netloc */
|
|
|
|
host = p;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Look for port specifier (colon) or end of host specifier
|
|
|
|
* (slash) or query (question mark) or host separator (comma).
|
2016-11-03 14:25:20 +01:00
|
|
|
*/
|
|
|
|
while (*p && *p != ':' && *p != '/' && *p != '?' && *p != ',')
|
|
|
|
++p;
|
|
|
|
}
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/* Save the hostname terminator before we null it */
|
|
|
|
prevchar = *p;
|
|
|
|
*p = '\0';
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
appendPQExpBufferStr(&hostbuf, host);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
if (prevchar == ':')
|
|
|
|
{
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
const char *port = ++p; /* advance past host terminator */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
while (*p && *p != '/' && *p != '?' && *p != ',')
|
|
|
|
++p;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
prevchar = *p;
|
|
|
|
*p = '\0';
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
appendPQExpBufferStr(&portbuf, port);
|
|
|
|
}
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
if (prevchar != ',')
|
|
|
|
break;
|
2017-05-17 22:31:56 +02:00
|
|
|
++p; /* advance past comma separator */
|
2017-08-16 05:34:39 +02:00
|
|
|
appendPQExpBufferChar(&hostbuf, ',');
|
|
|
|
appendPQExpBufferChar(&portbuf, ',');
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
/* Save final values for host and port. */
|
|
|
|
if (PQExpBufferDataBroken(hostbuf) || PQExpBufferDataBroken(portbuf))
|
|
|
|
goto cleanup;
|
|
|
|
if (hostbuf.data[0] &&
|
|
|
|
!conninfo_storeval(options, "host", hostbuf.data,
|
|
|
|
errorMessage, false, true))
|
|
|
|
goto cleanup;
|
|
|
|
if (portbuf.data[0] &&
|
|
|
|
!conninfo_storeval(options, "port", portbuf.data,
|
|
|
|
errorMessage, false, true))
|
|
|
|
goto cleanup;
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (prevchar && prevchar != '?')
|
|
|
|
{
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
const char *dbname = ++p; /* advance past host terminator */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
/* Look for query parameters */
|
|
|
|
while (*p && *p != '?')
|
|
|
|
++p;
|
|
|
|
|
|
|
|
prevchar = *p;
|
|
|
|
*p = '\0';
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid setting dbname to an empty string, as it forces the default
|
|
|
|
* value (username) and ignores $PGDATABASE, as opposed to not setting
|
|
|
|
* it at all.
|
|
|
|
*/
|
|
|
|
if (*dbname &&
|
|
|
|
!conninfo_storeval(options, "dbname", dbname,
|
|
|
|
errorMessage, false, true))
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prevchar)
|
|
|
|
{
|
2012-06-10 21:20:04 +02:00
|
|
|
++p; /* advance past terminator */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
if (!conninfo_uri_parse_params(p, options, errorMessage))
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* everything parsed okay */
|
|
|
|
retval = true;
|
|
|
|
|
|
|
|
cleanup:
|
2016-11-03 14:25:20 +01:00
|
|
|
termPQExpBuffer(&hostbuf);
|
|
|
|
termPQExpBuffer(&portbuf);
|
2016-11-22 21:32:13 +01:00
|
|
|
if (buf)
|
|
|
|
free(buf);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Connection URI parameters parser routine
|
|
|
|
*
|
|
|
|
* If successful, returns true while connOptions is filled with parsed
|
2014-05-06 18:12:18 +02:00
|
|
|
* parameters. Otherwise, returns false and fills errorMessage appropriately.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*
|
|
|
|
* Destructively modifies 'params' buffer.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
conninfo_uri_parse_params(char *params,
|
|
|
|
PQconninfoOption *connOptions,
|
|
|
|
PQExpBuffer errorMessage)
|
|
|
|
{
|
|
|
|
while (*params)
|
|
|
|
{
|
2012-06-10 21:20:04 +02:00
|
|
|
char *keyword = params;
|
|
|
|
char *value = NULL;
|
|
|
|
char *p = params;
|
|
|
|
bool malloced = false;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the params string for '=' and '&', marking the end of keyword
|
|
|
|
* and value respectively.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
if (*p == '=')
|
|
|
|
{
|
|
|
|
/* Was there '=' already? */
|
|
|
|
if (value != NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
2012-07-02 20:12:46 +02:00
|
|
|
libpq_gettext("extra key/value separator \"=\" in URI query parameter: \"%s\"\n"),
|
2015-02-21 19:27:12 +01:00
|
|
|
keyword);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
/* Cut off keyword, advance to value */
|
2015-02-21 19:27:12 +01:00
|
|
|
*p++ = '\0';
|
|
|
|
value = p;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
else if (*p == '&' || *p == '\0')
|
|
|
|
{
|
2015-02-21 19:27:12 +01:00
|
|
|
/*
|
|
|
|
* If not at the end, cut off value and advance; leave p
|
|
|
|
* pointing to start of the next parameter, if any.
|
|
|
|
*/
|
|
|
|
if (*p != '\0')
|
|
|
|
*p++ = '\0';
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/* Was there '=' at all? */
|
|
|
|
if (value == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
2012-07-02 20:12:46 +02:00
|
|
|
libpq_gettext("missing key/value separator \"=\" in URI query parameter: \"%s\"\n"),
|
2015-02-21 19:27:12 +01:00
|
|
|
keyword);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
return false;
|
|
|
|
}
|
2015-02-21 19:27:12 +01:00
|
|
|
/* Got keyword and value, go process them. */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
break;
|
|
|
|
}
|
2015-02-21 18:59:25 +01:00
|
|
|
else
|
|
|
|
++p; /* Advance over all other bytes. */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
|
2012-05-28 21:44:34 +02:00
|
|
|
keyword = conninfo_uri_decode(keyword, errorMessage);
|
|
|
|
if (keyword == NULL)
|
|
|
|
{
|
|
|
|
/* conninfo_uri_decode already set an error message */
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
value = conninfo_uri_decode(value, errorMessage);
|
|
|
|
if (value == NULL)
|
|
|
|
{
|
|
|
|
/* conninfo_uri_decode already set an error message */
|
|
|
|
free(keyword);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
malloced = true;
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
/*
|
2012-05-28 21:44:34 +02:00
|
|
|
* Special keyword handling for improved JDBC compatibility.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
|
|
|
if (strcmp(keyword, "ssl") == 0 &&
|
|
|
|
strcmp(value, "true") == 0)
|
|
|
|
{
|
2012-05-28 21:44:34 +02:00
|
|
|
free(keyword);
|
|
|
|
free(value);
|
|
|
|
malloced = false;
|
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
keyword = "sslmode";
|
|
|
|
value = "require";
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Store the value if the corresponding option exists; ignore
|
2012-05-28 21:44:34 +02:00
|
|
|
* otherwise. At this point both keyword and value are not
|
|
|
|
* URI-encoded.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
|
|
|
if (!conninfo_storeval(connOptions, keyword, value,
|
2012-05-28 21:44:34 +02:00
|
|
|
errorMessage, true, false))
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
{
|
2015-02-21 19:27:12 +01:00
|
|
|
/* Insert generic message if conninfo_storeval didn't give one. */
|
|
|
|
if (errorMessage->len == 0)
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid URI query parameter: \"%s\"\n"),
|
2015-02-21 19:27:12 +01:00
|
|
|
keyword);
|
|
|
|
/* And fail. */
|
2012-08-24 04:33:04 +02:00
|
|
|
if (malloced)
|
|
|
|
{
|
|
|
|
free(keyword);
|
|
|
|
free(value);
|
|
|
|
}
|
2012-06-08 14:46:39 +02:00
|
|
|
return false;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
2015-02-21 19:27:12 +01:00
|
|
|
|
2012-05-28 21:44:34 +02:00
|
|
|
if (malloced)
|
|
|
|
{
|
|
|
|
free(keyword);
|
|
|
|
free(value);
|
|
|
|
}
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2015-02-21 19:27:12 +01:00
|
|
|
/* Proceed to next key=value pair, if any */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
params = p;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Connection URI decoder routine
|
|
|
|
*
|
|
|
|
* If successful, returns the malloc'd decoded string.
|
|
|
|
* If not successful, returns NULL and fills errorMessage accordingly.
|
|
|
|
*
|
|
|
|
* The string is decoded by replacing any percent-encoded tokens with
|
|
|
|
* corresponding characters, while preserving any non-encoded characters. A
|
|
|
|
* percent-encoded token is a character triplet: a percent sign, followed by a
|
|
|
|
* pair of hexadecimal digits (0-9A-F), where lower- and upper-case letters are
|
|
|
|
* treated identically.
|
|
|
|
*/
|
1999-02-05 05:25:55 +01:00
|
|
|
static char *
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
conninfo_uri_decode(const char *str, PQExpBuffer errorMessage)
|
|
|
|
{
|
2014-11-25 11:55:00 +01:00
|
|
|
char *buf;
|
|
|
|
char *p;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
const char *q = str;
|
|
|
|
|
2014-11-25 11:55:00 +01:00
|
|
|
buf = malloc(strlen(str) + 1);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (buf == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("out of memory\n"));
|
|
|
|
return NULL;
|
|
|
|
}
|
2014-11-25 11:55:00 +01:00
|
|
|
p = buf;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
if (*q != '%')
|
|
|
|
{
|
|
|
|
/* copy and check for NUL terminator */
|
|
|
|
if (!(*(p++) = *(q++)))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2012-06-10 21:20:04 +02:00
|
|
|
int hi;
|
|
|
|
int lo;
|
|
|
|
int c;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2012-06-10 21:20:04 +02:00
|
|
|
++q; /* skip the percent sign itself */
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* Possible EOL will be caught by the first call to
|
|
|
|
* get_hexdigit(), so we never dereference an invalid q pointer.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
|
|
|
if (!(get_hexdigit(*q++, &hi) && get_hexdigit(*q++, &lo)))
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid percent-encoded token: \"%s\"\n"),
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
str);
|
|
|
|
free(buf);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
c = (hi << 4) | lo;
|
|
|
|
if (c == 0)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage,
|
2012-07-02 20:12:46 +02:00
|
|
|
libpq_gettext("forbidden value %%00 in percent-encoded value: \"%s\"\n"),
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
str);
|
|
|
|
free(buf);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
*(p++) = c;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert hexadecimal digit character to its integer value.
|
|
|
|
*
|
|
|
|
* If successful, returns true and value is filled with digit's base 16 value.
|
|
|
|
* If not successful, returns false.
|
|
|
|
*
|
|
|
|
* Lower- and upper-case letters in the range A-F are treated identically.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
get_hexdigit(char digit, int *value)
|
|
|
|
{
|
|
|
|
if ('0' <= digit && digit <= '9')
|
|
|
|
*value = digit - '0';
|
|
|
|
else if ('A' <= digit && digit <= 'F')
|
|
|
|
*value = digit - 'A' + 10;
|
|
|
|
else if ('a' <= digit && digit <= 'f')
|
|
|
|
*value = digit - 'a' + 10;
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find an option value corresponding to the keyword in the connOptions array.
|
|
|
|
*
|
|
|
|
* If successful, returns a pointer to the corresponding option's value.
|
|
|
|
* If not successful, returns NULL.
|
|
|
|
*/
|
|
|
|
static const char *
|
2000-03-11 04:08:37 +01:00
|
|
|
conninfo_getval(PQconninfoOption *connOptions,
|
|
|
|
const char *keyword)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
PQconninfoOption *option;
|
1996-11-09 11:39:54 +01:00
|
|
|
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
option = conninfo_find(connOptions, keyword);
|
|
|
|
|
|
|
|
return option ? option->val : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Store a (new) value for an option corresponding to the keyword in
|
|
|
|
* connOptions array.
|
|
|
|
*
|
2012-05-28 21:44:34 +02:00
|
|
|
* If uri_decode is true, the value is URI-decoded. The keyword is always
|
|
|
|
* assumed to be non URI-encoded.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*
|
|
|
|
* If successful, returns a pointer to the corresponding PQconninfoOption,
|
|
|
|
* which value is replaced with a strdup'd copy of the passed value string.
|
|
|
|
* The existing value for the option is free'd before replacing, if any.
|
|
|
|
*
|
|
|
|
* If not successful, returns NULL and fills errorMessage accordingly.
|
|
|
|
* However, if the reason of failure is an invalid keyword being passed and
|
2017-08-16 06:22:32 +02:00
|
|
|
* ignoreMissing is true, errorMessage will be left untouched.
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
|
|
|
conninfo_storeval(PQconninfoOption *connOptions,
|
|
|
|
const char *keyword, const char *value,
|
|
|
|
PQExpBuffer errorMessage, bool ignoreMissing,
|
|
|
|
bool uri_decode)
|
|
|
|
{
|
|
|
|
PQconninfoOption *option;
|
2012-06-10 21:20:04 +02:00
|
|
|
char *value_copy;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
|
2012-11-30 07:09:18 +01:00
|
|
|
/*
|
|
|
|
* For backwards compatibility, requiressl=1 gets translated to
|
|
|
|
* sslmode=require, and requiressl=0 gets translated to sslmode=prefer
|
|
|
|
* (which is the default for sslmode).
|
|
|
|
*/
|
|
|
|
if (strcmp(keyword, "requiressl") == 0)
|
|
|
|
{
|
|
|
|
keyword = "sslmode";
|
|
|
|
if (value[0] == '1')
|
|
|
|
value = "require";
|
|
|
|
else
|
|
|
|
value = "prefer";
|
|
|
|
}
|
|
|
|
|
2012-05-28 21:44:34 +02:00
|
|
|
option = conninfo_find(connOptions, keyword);
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
if (option == NULL)
|
|
|
|
{
|
|
|
|
if (!ignoreMissing)
|
|
|
|
printfPQExpBuffer(errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("invalid connection option \"%s\"\n"),
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
keyword);
|
2012-05-28 21:44:34 +02:00
|
|
|
return NULL;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (uri_decode)
|
|
|
|
{
|
|
|
|
value_copy = conninfo_uri_decode(value, errorMessage);
|
|
|
|
if (value_copy == NULL)
|
|
|
|
/* conninfo_uri_decode already set an error message */
|
2012-05-28 21:44:34 +02:00
|
|
|
return NULL;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
value_copy = strdup(value);
|
|
|
|
if (value_copy == NULL)
|
|
|
|
{
|
|
|
|
printfPQExpBuffer(errorMessage, libpq_gettext("out of memory\n"));
|
2012-05-28 21:44:34 +02:00
|
|
|
return NULL;
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (option->val)
|
|
|
|
free(option->val);
|
|
|
|
option->val = value_copy;
|
|
|
|
|
|
|
|
return option;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find a PQconninfoOption option corresponding to the keyword in the
|
|
|
|
* connOptions array.
|
|
|
|
*
|
|
|
|
* If successful, returns a pointer to the corresponding PQconninfoOption
|
|
|
|
* structure.
|
|
|
|
* If not successful, returns NULL.
|
|
|
|
*/
|
|
|
|
static PQconninfoOption *
|
|
|
|
conninfo_find(PQconninfoOption *connOptions, const char *keyword)
|
|
|
|
{
|
|
|
|
PQconninfoOption *option;
|
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
for (option = connOptions; option->keyword != NULL; option++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-03-11 04:08:37 +01:00
|
|
|
if (strcmp(option->keyword, keyword) == 0)
|
Accept postgres:// URIs in libpq connection functions
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.
2012-04-11 08:59:32 +02:00
|
|
|
return option;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
return NULL;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-11-30 07:09:18 +01:00
|
|
|
/*
|
|
|
|
* Return the connection options used for the connection
|
|
|
|
*/
|
|
|
|
PQconninfoOption *
|
|
|
|
PQconninfo(PGconn *conn)
|
|
|
|
{
|
|
|
|
PQExpBufferData errorBuf;
|
|
|
|
PQconninfoOption *connOptions;
|
|
|
|
|
|
|
|
if (conn == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* We don't actually report any errors here, but callees want a buffer */
|
|
|
|
initPQExpBuffer(&errorBuf);
|
|
|
|
if (PQExpBufferDataBroken(errorBuf))
|
|
|
|
return NULL; /* out of memory already :-( */
|
|
|
|
|
|
|
|
connOptions = conninfo_init(&errorBuf);
|
|
|
|
|
|
|
|
if (connOptions != NULL)
|
|
|
|
{
|
|
|
|
const internalPQconninfoOption *option;
|
|
|
|
|
|
|
|
for (option = PQconninfoOptions; option->keyword; option++)
|
|
|
|
{
|
|
|
|
char **connmember;
|
|
|
|
|
|
|
|
if (option->connofs < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
connmember = (char **) ((char *) conn + option->connofs);
|
|
|
|
|
|
|
|
if (*connmember)
|
|
|
|
conninfo_storeval(connOptions, option->keyword, *connmember,
|
|
|
|
&errorBuf, true, false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
termPQExpBuffer(&errorBuf);
|
|
|
|
|
|
|
|
return connOptions;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
void
|
|
|
|
PQconninfoFree(PQconninfoOption *connOptions)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
PQconninfoOption *option;
|
1996-11-09 11:39:54 +01:00
|
|
|
|
2000-03-11 04:08:37 +01:00
|
|
|
if (connOptions == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (option = connOptions; option->keyword != NULL; option++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
if (option->val != NULL)
|
|
|
|
free(option->val);
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
2000-03-11 04:08:37 +01:00
|
|
|
free(connOptions);
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
2001-11-11 03:09:05 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* =========== accessor functions for PGconn ========= */
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQdb(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
return conn->dbName;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQuser(const PGconn *conn)
|
1996-11-09 11:39:54 +01:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
return conn->pguser;
|
1996-11-09 11:39:54 +01:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQpass(const PGconn *conn)
|
1998-09-03 04:10:56 +02:00
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
char *password = NULL;
|
2016-11-03 14:25:20 +01:00
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->connhost != NULL)
|
|
|
|
password = conn->connhost[conn->whichhost].password;
|
|
|
|
if (password == NULL)
|
|
|
|
password = conn->pgpass;
|
2017-01-24 23:06:21 +01:00
|
|
|
/* Historically we've returned "" not NULL for no password specified */
|
|
|
|
if (password == NULL)
|
|
|
|
password = "";
|
2016-11-03 14:25:20 +01:00
|
|
|
return password;
|
1998-09-03 04:10:56 +02:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQhost(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
2018-03-27 18:31:34 +02:00
|
|
|
|
|
|
|
if (conn->connhost != NULL)
|
2014-01-23 14:48:12 +01:00
|
|
|
{
|
2018-03-27 18:31:34 +02:00
|
|
|
if (conn->connhost[conn->whichhost].host != NULL &&
|
|
|
|
conn->connhost[conn->whichhost].host[0] != '\0')
|
|
|
|
return conn->connhost[conn->whichhost].host;
|
|
|
|
else if (conn->connhost[conn->whichhost].hostaddr != NULL &&
|
|
|
|
conn->connhost[conn->whichhost].hostaddr[0] != '\0')
|
|
|
|
return conn->connhost[conn->whichhost].hostaddr;
|
2014-01-23 14:48:12 +01:00
|
|
|
}
|
2018-03-27 18:31:34 +02:00
|
|
|
|
|
|
|
return "";
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQport(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
2018-03-27 18:31:34 +02:00
|
|
|
|
2016-11-03 14:25:20 +01:00
|
|
|
if (conn->connhost != NULL)
|
|
|
|
return conn->connhost[conn->whichhost].port;
|
2018-03-27 18:31:34 +02:00
|
|
|
|
|
|
|
return "";
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQtty(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
return conn->pgtty;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQoptions(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2004-01-07 19:56:30 +01:00
|
|
|
return NULL;
|
1998-09-03 04:10:56 +02:00
|
|
|
return conn->pgoptions;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
ConnStatusType
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQstatus(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
|
|
|
return CONNECTION_BAD;
|
|
|
|
return conn->status;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
PGTransactionStatusType
|
|
|
|
PQtransactionStatus(const PGconn *conn)
|
|
|
|
{
|
|
|
|
if (!conn || conn->status != CONNECTION_OK)
|
|
|
|
return PQTRANS_UNKNOWN;
|
|
|
|
if (conn->asyncStatus != PGASYNC_IDLE)
|
|
|
|
return PQTRANS_ACTIVE;
|
|
|
|
return conn->xactStatus;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
PQparameterStatus(const PGconn *conn, const char *paramName)
|
|
|
|
{
|
|
|
|
const pgParameterStatus *pstatus;
|
|
|
|
|
|
|
|
if (!conn || !paramName)
|
|
|
|
return NULL;
|
|
|
|
for (pstatus = conn->pstatus; pstatus != NULL; pstatus = pstatus->next)
|
|
|
|
{
|
|
|
|
if (strcmp(pstatus->name, paramName) == 0)
|
|
|
|
return pstatus->value;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
PQprotocolVersion(const PGconn *conn)
|
|
|
|
{
|
|
|
|
if (!conn)
|
|
|
|
return 0;
|
|
|
|
if (conn->status == CONNECTION_BAD)
|
|
|
|
return 0;
|
|
|
|
return PG_PROTOCOL_MAJOR(conn->pversion);
|
|
|
|
}
|
|
|
|
|
2004-08-11 20:06:01 +02:00
|
|
|
int
|
|
|
|
PQserverVersion(const PGconn *conn)
|
|
|
|
{
|
|
|
|
if (!conn)
|
|
|
|
return 0;
|
|
|
|
if (conn->status == CONNECTION_BAD)
|
|
|
|
return 0;
|
|
|
|
return conn->sversion;
|
|
|
|
}
|
|
|
|
|
2000-02-08 00:10:11 +01:00
|
|
|
char *
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQerrorMessage(const PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!conn)
|
2001-07-15 15:45:04 +02:00
|
|
|
return libpq_gettext("connection pointer is NULL\n");
|
2000-03-11 04:08:37 +01:00
|
|
|
|
1999-08-31 03:37:37 +02:00
|
|
|
return conn->errorMessage.data;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2014-04-16 16:45:48 +02:00
|
|
|
/*
|
|
|
|
* In Windows, socket values are unsigned, and an invalid socket value
|
|
|
|
* (INVALID_SOCKET) is ~0, which equals -1 in comparisons (with no compiler
|
|
|
|
* warning). Ideally we would return an unsigned value for PQsocket() on
|
|
|
|
* Windows, but that would cause the function's return value to differ from
|
|
|
|
* Unix, so we just return -1 for invalid sockets.
|
|
|
|
* http://msdn.microsoft.com/en-us/library/windows/desktop/cc507522%28v=vs.85%29.aspx
|
|
|
|
* http://stackoverflow.com/questions/10817252/why-is-invalid-socket-defined-as-0-in-winsock2-h-c
|
|
|
|
*/
|
1998-05-07 01:51:16 +02:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQsocket(const PGconn *conn)
|
1998-05-07 01:51:16 +02:00
|
|
|
{
|
|
|
|
if (!conn)
|
|
|
|
return -1;
|
2014-04-17 01:46:51 +02:00
|
|
|
return (conn->sock != PGINVALID_SOCKET) ? conn->sock : -1;
|
1998-05-07 01:51:16 +02:00
|
|
|
}
|
|
|
|
|
1998-09-03 04:10:56 +02:00
|
|
|
int
|
In the spirit of TODO item
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
1999-11-11 01:10:14 +01:00
|
|
|
PQbackendPID(const PGconn *conn)
|
1998-09-03 04:10:56 +02:00
|
|
|
{
|
|
|
|
if (!conn || conn->status != CONNECTION_OK)
|
|
|
|
return 0;
|
|
|
|
return conn->be_pid;
|
|
|
|
}
|
|
|
|
|
2007-12-09 20:01:40 +01:00
|
|
|
int
|
|
|
|
PQconnectionNeedsPassword(const PGconn *conn)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
char *password;
|
2016-11-03 14:25:20 +01:00
|
|
|
|
2007-12-09 20:01:40 +01:00
|
|
|
if (!conn)
|
|
|
|
return false;
|
2016-11-03 14:25:20 +01:00
|
|
|
password = PQpass(conn);
|
2007-12-09 20:01:40 +01:00
|
|
|
if (conn->password_needed &&
|
2016-11-03 14:25:20 +01:00
|
|
|
(password == NULL || password[0] == '\0'))
|
2007-12-09 20:01:40 +01:00
|
|
|
return true;
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2007-07-08 20:28:56 +02:00
|
|
|
int
|
|
|
|
PQconnectionUsedPassword(const PGconn *conn)
|
|
|
|
{
|
|
|
|
if (!conn)
|
|
|
|
return false;
|
2008-09-22 16:21:44 +02:00
|
|
|
if (conn->password_needed)
|
2007-07-08 20:28:56 +02:00
|
|
|
return true;
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2000-01-15 06:37:21 +01:00
|
|
|
int
|
2000-02-05 13:33:22 +01:00
|
|
|
PQclientEncoding(const PGconn *conn)
|
2000-01-15 06:37:21 +01:00
|
|
|
{
|
|
|
|
if (!conn || conn->status != CONNECTION_OK)
|
|
|
|
return -1;
|
|
|
|
return conn->client_encoding;
|
|
|
|
}
|
|
|
|
|
2000-02-05 13:33:22 +01:00
|
|
|
int
|
|
|
|
PQsetClientEncoding(PGconn *conn, const char *encoding)
|
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
char qbuf[128];
|
2004-03-24 04:45:00 +01:00
|
|
|
static const char query[] = "set client_encoding to '%s'";
|
2000-04-12 19:17:23 +02:00
|
|
|
PGresult *res;
|
|
|
|
int status;
|
2000-02-05 13:33:22 +01:00
|
|
|
|
|
|
|
if (!conn || conn->status != CONNECTION_OK)
|
|
|
|
return -1;
|
|
|
|
|
2000-02-19 06:04:54 +01:00
|
|
|
if (!encoding)
|
|
|
|
return -1;
|
|
|
|
|
2011-02-19 07:54:58 +01:00
|
|
|
/* Resolve special "auto" value from the locale */
|
|
|
|
if (strcmp(encoding, "auto") == 0)
|
|
|
|
encoding = pg_encoding_to_char(pg_get_encoding_from_locale(NULL, true));
|
|
|
|
|
2000-02-05 13:33:22 +01:00
|
|
|
/* check query buffer overflow */
|
|
|
|
if (sizeof(qbuf) < (sizeof(query) + strlen(encoding)))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/* ok, now send a query */
|
|
|
|
sprintf(qbuf, query, encoding);
|
|
|
|
res = PQexec(conn, qbuf);
|
|
|
|
|
2004-01-07 19:56:30 +01:00
|
|
|
if (res == NULL)
|
2000-02-05 13:33:22 +01:00
|
|
|
return -1;
|
|
|
|
if (res->resultStatus != PGRES_COMMAND_OK)
|
|
|
|
status = -1;
|
|
|
|
else
|
|
|
|
{
|
Modify libpq's string-escaping routines to be aware of encoding considerations
and standard_conforming_strings. The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection. An actual fix requires changing the
client-side code. While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.
Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn. The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables. This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.
Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(. It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* In protocol 2 we have to assume the setting will stick, and adjust
|
|
|
|
* our state immediately. In protocol 3 and up we can rely on the
|
|
|
|
* backend to report the parameter value, and we'll change state at
|
|
|
|
* that time.
|
Modify libpq's string-escaping routines to be aware of encoding considerations
and standard_conforming_strings. The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection. An actual fix requires changing the
client-side code. While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.
Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn. The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables. This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.
Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(. It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.
2006-05-21 22:19:23 +02:00
|
|
|
*/
|
|
|
|
if (PG_PROTOCOL_MAJOR(conn->pversion) < 3)
|
|
|
|
pqSaveParameterStatus(conn, "client_encoding", encoding);
|
2000-04-12 19:17:23 +02:00
|
|
|
status = 0; /* everything is ok */
|
2000-02-05 13:33:22 +01:00
|
|
|
}
|
|
|
|
PQclear(res);
|
2006-01-11 09:43:13 +01:00
|
|
|
return status;
|
2000-02-05 13:33:22 +01:00
|
|
|
}
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
PGVerbosity
|
|
|
|
PQsetErrorVerbosity(PGconn *conn, PGVerbosity verbosity)
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
PGVerbosity old;
|
2003-06-21 23:51:35 +02:00
|
|
|
|
|
|
|
if (!conn)
|
|
|
|
return PQERRORS_DEFAULT;
|
|
|
|
old = conn->verbosity;
|
|
|
|
conn->verbosity = verbosity;
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
2015-09-05 17:58:20 +02:00
|
|
|
PGContextVisibility
|
|
|
|
PQsetErrorContextVisibility(PGconn *conn, PGContextVisibility show_context)
|
|
|
|
{
|
|
|
|
PGContextVisibility old;
|
|
|
|
|
|
|
|
if (!conn)
|
|
|
|
return PQSHOW_CONTEXT_ERRORS;
|
|
|
|
old = conn->show_context;
|
|
|
|
conn->show_context = show_context;
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
void
|
1997-09-08 23:56:23 +02:00
|
|
|
PQtrace(PGconn *conn, FILE *debug_port)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-06-21 23:51:35 +02:00
|
|
|
if (conn == NULL)
|
1997-09-07 07:04:48 +02:00
|
|
|
return;
|
|
|
|
PQuntrace(conn);
|
|
|
|
conn->Pfdebug = debug_port;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
void
|
1997-09-08 23:56:23 +02:00
|
|
|
PQuntrace(PGconn *conn)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-05-07 01:51:16 +02:00
|
|
|
if (conn == NULL)
|
1997-09-07 07:04:48 +02:00
|
|
|
return;
|
|
|
|
if (conn->Pfdebug)
|
|
|
|
{
|
|
|
|
fflush(conn->Pfdebug);
|
|
|
|
conn->Pfdebug = NULL;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1998-08-09 04:59:33 +02:00
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
PQnoticeReceiver
|
|
|
|
PQsetNoticeReceiver(PGconn *conn, PQnoticeReceiver proc, void *arg)
|
|
|
|
{
|
|
|
|
PQnoticeReceiver old;
|
|
|
|
|
|
|
|
if (conn == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
old = conn->noticeHooks.noticeRec;
|
|
|
|
if (proc)
|
|
|
|
{
|
|
|
|
conn->noticeHooks.noticeRec = proc;
|
|
|
|
conn->noticeHooks.noticeRecArg = arg;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
1999-10-26 06:49:00 +02:00
|
|
|
PQnoticeProcessor
|
1998-09-01 06:40:42 +02:00
|
|
|
PQsetNoticeProcessor(PGconn *conn, PQnoticeProcessor proc, void *arg)
|
1998-08-09 04:59:33 +02:00
|
|
|
{
|
1999-10-26 06:49:00 +02:00
|
|
|
PQnoticeProcessor old;
|
2000-03-11 04:08:37 +01:00
|
|
|
|
1998-08-09 04:59:33 +02:00
|
|
|
if (conn == NULL)
|
1999-10-26 06:49:00 +02:00
|
|
|
return NULL;
|
|
|
|
|
2003-06-21 23:51:35 +02:00
|
|
|
old = conn->noticeHooks.noticeProc;
|
2000-03-11 04:08:37 +01:00
|
|
|
if (proc)
|
|
|
|
{
|
2003-06-21 23:51:35 +02:00
|
|
|
conn->noticeHooks.noticeProc = proc;
|
|
|
|
conn->noticeHooks.noticeProcArg = arg;
|
1999-10-26 06:49:00 +02:00
|
|
|
}
|
|
|
|
return old;
|
1998-08-09 04:59:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2003-06-21 23:51:35 +02:00
|
|
|
* The default notice message receiver just gets the standard notice text
|
|
|
|
* and sends it to the notice processor. This two-level setup exists
|
|
|
|
* mostly for backwards compatibility; perhaps we should deprecate use of
|
|
|
|
* PQsetNoticeProcessor?
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
defaultNoticeReceiver(void *arg, const PGresult *res)
|
|
|
|
{
|
|
|
|
(void) arg; /* not used */
|
2003-06-23 21:20:25 +02:00
|
|
|
if (res->noticeHooks.noticeProc != NULL)
|
2017-09-07 18:06:23 +02:00
|
|
|
res->noticeHooks.noticeProc(res->noticeHooks.noticeProcArg,
|
|
|
|
PQresultErrorMessage(res));
|
2003-06-21 23:51:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The default notice message processor just prints the
|
1998-08-09 04:59:33 +02:00
|
|
|
* message on stderr. Applications can override this if they
|
|
|
|
* want the messages to go elsewhere (a window, for example).
|
|
|
|
* Note that simply discarding notices is probably a bad idea.
|
|
|
|
*/
|
|
|
|
static void
|
1998-09-01 06:40:42 +02:00
|
|
|
defaultNoticeProcessor(void *arg, const char *message)
|
1998-08-09 04:59:33 +02:00
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
(void) arg; /* not used */
|
1998-08-09 04:59:33 +02:00
|
|
|
/* Note: we expect the supplied string to end with a newline already. */
|
|
|
|
fprintf(stderr, "%s", message);
|
|
|
|
}
|
2002-08-15 04:56:19 +02:00
|
|
|
|
2003-04-18 00:26:02 +02:00
|
|
|
/*
|
|
|
|
* returns a pointer to the next token or NULL if the current
|
|
|
|
* token doesn't match
|
|
|
|
*/
|
|
|
|
static char *
|
2017-10-31 15:34:31 +01:00
|
|
|
pwdfMatchesString(char *buf, const char *token)
|
2002-08-15 04:56:19 +02:00
|
|
|
{
|
2017-10-31 15:34:31 +01:00
|
|
|
char *tbuf;
|
|
|
|
const char *ttok;
|
2002-09-04 22:31:48 +02:00
|
|
|
bool bslash = false;
|
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
if (buf == NULL || token == NULL)
|
|
|
|
return NULL;
|
|
|
|
tbuf = buf;
|
|
|
|
ttok = token;
|
2009-05-18 18:15:22 +02:00
|
|
|
if (tbuf[0] == '*' && tbuf[1] == ':')
|
2002-08-15 04:56:19 +02:00
|
|
|
return tbuf + 2;
|
|
|
|
while (*tbuf != 0)
|
|
|
|
{
|
|
|
|
if (*tbuf == '\\' && !bslash)
|
|
|
|
{
|
|
|
|
tbuf++;
|
|
|
|
bslash = true;
|
|
|
|
}
|
|
|
|
if (*tbuf == ':' && *ttok == 0 && !bslash)
|
2002-09-04 22:31:48 +02:00
|
|
|
return tbuf + 1;
|
2002-08-15 04:56:19 +02:00
|
|
|
bslash = false;
|
|
|
|
if (*ttok == 0)
|
|
|
|
return NULL;
|
|
|
|
if (*tbuf == *ttok)
|
|
|
|
{
|
|
|
|
tbuf++;
|
|
|
|
ttok++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2003-01-30 20:49:54 +01:00
|
|
|
/* Get a password from the password file. Return value is malloc'd. */
|
2003-04-18 00:26:02 +02:00
|
|
|
static char *
|
2017-10-31 15:34:31 +01:00
|
|
|
passwordFromFile(const char *hostname, const char *port, const char *dbname,
|
|
|
|
const char *username, const char *pgpassfile)
|
2002-08-15 04:56:19 +02:00
|
|
|
{
|
2002-09-04 22:31:48 +02:00
|
|
|
FILE *fp;
|
2002-09-06 00:05:50 +02:00
|
|
|
struct stat stat_buf;
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
#define LINELEN NAMEDATALEN*5
|
2002-09-04 22:31:48 +02:00
|
|
|
char buf[LINELEN];
|
2002-08-15 04:56:19 +02:00
|
|
|
|
2002-09-06 00:05:50 +02:00
|
|
|
if (dbname == NULL || strlen(dbname) == 0)
|
2002-08-15 04:56:19 +02:00
|
|
|
return NULL;
|
|
|
|
|
2002-09-06 00:05:50 +02:00
|
|
|
if (username == NULL || strlen(username) == 0)
|
2002-08-15 04:56:19 +02:00
|
|
|
return NULL;
|
|
|
|
|
2006-05-17 23:50:54 +02:00
|
|
|
/* 'localhost' matches pghost of '' or the default socket directory */
|
2002-08-15 04:56:19 +02:00
|
|
|
if (hostname == NULL)
|
|
|
|
hostname = DefaultHost;
|
2006-05-17 23:50:54 +02:00
|
|
|
else if (is_absolute_path(hostname))
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2006-05-18 18:26:44 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* We should probably use canonicalize_path(), but then we have to
|
|
|
|
* bring path.c into libpq, and it doesn't seem worth it.
|
2006-05-18 18:26:44 +02:00
|
|
|
*/
|
|
|
|
if (strcmp(hostname, DEFAULT_PGSOCKET_DIR) == 0)
|
2006-05-17 23:50:54 +02:00
|
|
|
hostname = DefaultHost;
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
if (port == NULL)
|
|
|
|
port = DEF_PGPORT_STR;
|
|
|
|
|
2002-08-30 01:06:32 +02:00
|
|
|
/* If password file cannot be opened, ignore it. */
|
2008-03-31 04:43:14 +02:00
|
|
|
if (stat(pgpassfile, &stat_buf) != 0)
|
2002-08-30 01:06:32 +02:00
|
|
|
return NULL;
|
|
|
|
|
2005-06-19 15:10:56 +02:00
|
|
|
#ifndef WIN32
|
2005-06-10 05:02:30 +02:00
|
|
|
if (!S_ISREG(stat_buf.st_mode))
|
|
|
|
{
|
|
|
|
fprintf(stderr,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("WARNING: password file \"%s\" is not a plain file\n"),
|
2005-06-10 05:02:30 +02:00
|
|
|
pgpassfile);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2002-08-30 01:06:32 +02:00
|
|
|
/* If password file is insecure, alert the user and ignore it. */
|
|
|
|
if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
|
|
|
|
{
|
|
|
|
fprintf(stderr,
|
2008-03-31 04:43:14 +02:00
|
|
|
libpq_gettext("WARNING: password file \"%s\" has group or world access; permissions should be u=rw (0600) or less\n"),
|
2002-09-06 00:05:50 +02:00
|
|
|
pgpassfile);
|
2002-08-30 01:06:32 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2007-02-20 16:20:51 +01:00
|
|
|
#else
|
2007-11-15 22:14:46 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* On Win32, the directory is protected, so we don't have to check the
|
|
|
|
* file.
|
|
|
|
*/
|
2002-10-03 19:09:42 +02:00
|
|
|
#endif
|
2002-08-30 01:06:32 +02:00
|
|
|
|
2002-09-06 00:05:50 +02:00
|
|
|
fp = fopen(pgpassfile, "r");
|
2002-08-15 04:56:19 +02:00
|
|
|
if (fp == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2010-03-03 21:31:09 +01:00
|
|
|
while (!feof(fp) && !ferror(fp))
|
2002-09-04 22:31:48 +02:00
|
|
|
{
|
|
|
|
char *t = buf,
|
2011-12-22 18:55:27 +01:00
|
|
|
*ret,
|
|
|
|
*p1,
|
|
|
|
*p2;
|
2003-01-30 20:49:54 +01:00
|
|
|
int len;
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2010-04-30 19:09:13 +02:00
|
|
|
if (fgets(buf, sizeof(buf), fp) == NULL)
|
|
|
|
break;
|
2003-01-30 20:49:54 +01:00
|
|
|
|
|
|
|
len = strlen(buf);
|
2002-08-15 04:56:19 +02:00
|
|
|
|
2003-01-30 20:49:54 +01:00
|
|
|
/* Remove trailing newline */
|
2016-11-15 22:17:19 +01:00
|
|
|
if (len > 0 && buf[len - 1] == '\n')
|
|
|
|
{
|
|
|
|
buf[--len] = '\0';
|
|
|
|
/* Handle DOS-style line endings, too, even when not on Windows */
|
|
|
|
if (len > 0 && buf[len - 1] == '\r')
|
|
|
|
buf[--len] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
if (len == 0)
|
|
|
|
continue;
|
2003-01-30 20:49:54 +01:00
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
if ((t = pwdfMatchesString(t, hostname)) == NULL ||
|
2002-09-04 22:31:48 +02:00
|
|
|
(t = pwdfMatchesString(t, port)) == NULL ||
|
|
|
|
(t = pwdfMatchesString(t, dbname)) == NULL ||
|
|
|
|
(t = pwdfMatchesString(t, username)) == NULL)
|
2002-08-15 04:56:19 +02:00
|
|
|
continue;
|
2016-11-15 22:17:19 +01:00
|
|
|
|
|
|
|
/* Found a match. */
|
2002-08-30 07:28:50 +02:00
|
|
|
ret = strdup(t);
|
2002-08-15 04:56:19 +02:00
|
|
|
fclose(fp);
|
2011-12-22 18:55:27 +01:00
|
|
|
|
2014-11-25 11:55:00 +01:00
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
/* Out of memory. XXX: an error message would be nice. */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2011-12-22 18:55:27 +01:00
|
|
|
/* De-escape password. */
|
|
|
|
for (p1 = p2 = ret; *p1 != ':' && *p1 != '\0'; ++p1, ++p2)
|
|
|
|
{
|
|
|
|
if (*p1 == '\\' && p1[1] != '\0')
|
|
|
|
++p1;
|
|
|
|
*p2 = *p1;
|
|
|
|
}
|
|
|
|
*p2 = '\0';
|
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
return ret;
|
|
|
|
}
|
2002-09-06 00:05:50 +02:00
|
|
|
|
2002-08-15 04:56:19 +02:00
|
|
|
fclose(fp);
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
#undef LINELEN
|
|
|
|
}
|
2004-01-09 03:02:43 +01:00
|
|
|
|
2010-03-13 15:55:57 +01:00
|
|
|
|
|
|
|
/*
|
2017-02-03 01:49:15 +01:00
|
|
|
* If the connection failed due to bad password, we should mention
|
|
|
|
* if we got the password from the pgpassfile.
|
2010-03-13 15:55:57 +01:00
|
|
|
*/
|
|
|
|
static void
|
2017-01-24 23:06:21 +01:00
|
|
|
pgpassfileWarning(PGconn *conn)
|
2010-03-13 15:55:57 +01:00
|
|
|
{
|
2017-01-24 23:06:21 +01:00
|
|
|
/* If it was 'invalid authorization', add pgpassfile mention */
|
2010-07-06 21:19:02 +02:00
|
|
|
/* only works with >= 9.0 servers */
|
2017-02-03 01:49:15 +01:00
|
|
|
if (conn->pgpassfile_used && conn->password_needed && conn->result)
|
2010-03-13 15:55:57 +01:00
|
|
|
{
|
2017-02-03 01:49:15 +01:00
|
|
|
const char *sqlstate = PQresultErrorField(conn->result,
|
|
|
|
PG_DIAG_SQLSTATE);
|
|
|
|
|
|
|
|
if (sqlstate && strcmp(sqlstate, ERRCODE_INVALID_PASSWORD) == 0)
|
|
|
|
appendPQExpBuffer(&conn->errorMessage,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
libpq_gettext("password retrieved from file \"%s\"\n"),
|
2017-02-03 01:49:15 +01:00
|
|
|
conn->pgpassfile);
|
2010-03-13 15:55:57 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-06 21:19:02 +02:00
|
|
|
|
2005-01-06 02:00:12 +01:00
|
|
|
/*
|
|
|
|
* Obtain user's home directory, return in given buffer
|
|
|
|
*
|
2005-01-06 19:29:11 +01:00
|
|
|
* On Unix, this actually returns the user's home directory. On Windows
|
|
|
|
* it returns the PostgreSQL-specific application data folder.
|
|
|
|
*
|
2005-01-06 02:00:12 +01:00
|
|
|
* This is essentially the same as get_home_path(), but we don't use that
|
|
|
|
* because we don't want to pull path.c into libpq (it pollutes application
|
Fix libpq to not require user's home directory to exist.
Some people like to run libpq-using applications in environments where
there's no home directory. We've broken that scenario before (cf commits
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making
it a hard error if we fail to get the home directory name while looking
for ~/.pgpass. The previous precedent is that if we can't get the home
directory name, we should just silently act as though the file we hoped
to find there doesn't exist. Rearrange the new code to honor that.
Looking around, the service-file code added by commit 41a4e4595 had the
same disease. Apparently, that escaped notice because it only runs when
a service name has been specified, which I guess the people who use this
scenario don't do. Nonetheless, it's wrong too, so fix that case as well.
Add a comment about this policy to pqGetHomeDirectory, in the probably
vain hope of forestalling the same error in future. And upgrade the
rather miserable commenting in parseServiceInfo, too.
In passing, also back off parseServiceInfo's assumption that only ENOENT
is an ignorable error from stat() when checking a service file. We would
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that
the far-better-tested code for ~/.pgpass treats all stat() failures alike,
I think this code ought to as well.
Per bug #14872 from Dan Watson. Back-patch the .pgpass change to v10
where ba005f193 came in. The service-file bugs are far older, so
back-patch the other changes to all supported branches.
Discussion: https://postgr.es/m/20171025200457.1471.34504@wrigleys.postgresql.org
2017-10-26 01:32:24 +02:00
|
|
|
* namespace).
|
|
|
|
*
|
|
|
|
* Returns true on success, false on failure to obtain the directory name.
|
|
|
|
*
|
|
|
|
* CAUTION: although in most situations failure is unexpected, there are users
|
|
|
|
* who like to run applications in a home-directory-less environment. On
|
|
|
|
* failure, you almost certainly DO NOT want to report an error. Just act as
|
|
|
|
* though whatever file you were hoping to find in the home directory isn't
|
|
|
|
* there (which it isn't).
|
2005-01-06 02:00:12 +01:00
|
|
|
*/
|
|
|
|
bool
|
|
|
|
pqGetHomeDirectory(char *buf, int bufsize)
|
|
|
|
{
|
|
|
|
#ifndef WIN32
|
|
|
|
char pwdbuf[BUFSIZ];
|
|
|
|
struct passwd pwdstr;
|
|
|
|
struct passwd *pwd = NULL;
|
|
|
|
|
Fix libpq's behavior when /etc/passwd isn't readable.
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
2015-01-11 18:35:44 +01:00
|
|
|
(void) pqGetpwuid(geteuid(), &pwdstr, pwdbuf, sizeof(pwdbuf), &pwd);
|
|
|
|
if (pwd == NULL)
|
2005-01-06 02:00:12 +01:00
|
|
|
return false;
|
2007-02-10 15:58:55 +01:00
|
|
|
strlcpy(buf, pwd->pw_dir, bufsize);
|
2005-01-06 02:00:12 +01:00
|
|
|
return true;
|
|
|
|
#else
|
2005-01-06 19:29:11 +01:00
|
|
|
char tmppath[MAX_PATH];
|
2005-01-06 02:00:12 +01:00
|
|
|
|
2005-01-06 19:29:11 +01:00
|
|
|
ZeroMemory(tmppath, sizeof(tmppath));
|
2005-01-26 20:24:03 +01:00
|
|
|
if (SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, tmppath) != S_OK)
|
2005-01-06 02:00:12 +01:00
|
|
|
return false;
|
2005-01-06 19:29:11 +01:00
|
|
|
snprintf(buf, bufsize, "%s/postgresql", tmppath);
|
2005-01-06 02:00:12 +01:00
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2004-03-24 04:45:00 +01:00
|
|
|
/*
|
|
|
|
* To keep the API consistent, the locking stubs are always provided, even
|
|
|
|
* if they are not required.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
default_threadlock(int acquire)
|
|
|
|
{
|
|
|
|
#ifdef ENABLE_THREAD_SAFETY
|
2004-06-19 06:22:17 +02:00
|
|
|
#ifndef WIN32
|
2004-03-24 04:45:00 +01:00
|
|
|
static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
|
2004-06-19 06:22:17 +02:00
|
|
|
#else
|
2004-07-12 16:23:28 +02:00
|
|
|
static pthread_mutex_t singlethread_lock = NULL;
|
|
|
|
static long mutex_initlock = 0;
|
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
if (singlethread_lock == NULL)
|
|
|
|
{
|
|
|
|
while (InterlockedExchange(&mutex_initlock, 1) == 1)
|
|
|
|
/* loop, another thread own the lock */ ;
|
2004-07-12 16:23:28 +02:00
|
|
|
if (singlethread_lock == NULL)
|
2008-05-16 20:30:53 +02:00
|
|
|
{
|
|
|
|
if (pthread_mutex_init(&singlethread_lock, NULL))
|
|
|
|
PGTHREAD_ERROR("failed to initialize mutex");
|
|
|
|
}
|
2004-08-29 07:07:03 +02:00
|
|
|
InterlockedExchange(&mutex_initlock, 0);
|
2004-07-12 16:23:28 +02:00
|
|
|
}
|
2004-06-19 06:22:17 +02:00
|
|
|
#endif
|
2004-03-24 04:45:00 +01:00
|
|
|
if (acquire)
|
2008-05-16 20:30:53 +02:00
|
|
|
{
|
|
|
|
if (pthread_mutex_lock(&singlethread_lock))
|
|
|
|
PGTHREAD_ERROR("failed to lock mutex");
|
|
|
|
}
|
2004-03-24 04:45:00 +01:00
|
|
|
else
|
2008-05-16 20:30:53 +02:00
|
|
|
{
|
|
|
|
if (pthread_mutex_unlock(&singlethread_lock))
|
|
|
|
PGTHREAD_ERROR("failed to unlock mutex");
|
|
|
|
}
|
2004-03-24 04:45:00 +01:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2004-12-03 00:20:21 +01:00
|
|
|
pgthreadlock_t
|
|
|
|
PQregisterThreadLock(pgthreadlock_t newhandler)
|
2004-03-24 04:45:00 +01:00
|
|
|
{
|
2004-12-03 00:20:21 +01:00
|
|
|
pgthreadlock_t prev = pg_g_threadlock;
|
2004-03-24 04:45:00 +01:00
|
|
|
|
|
|
|
if (newhandler)
|
2004-12-03 00:20:21 +01:00
|
|
|
pg_g_threadlock = newhandler;
|
2004-03-24 04:45:00 +01:00
|
|
|
else
|
2004-12-03 00:20:21 +01:00
|
|
|
pg_g_threadlock = default_threadlock;
|
|
|
|
|
2004-03-24 04:45:00 +01:00
|
|
|
return prev;
|
|
|
|
}
|