2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2004-09-17 23:14:19 +02:00
|
|
|
* oid2name, a PostgreSQL app to map OIDs on the filesystem
|
|
|
|
* to table and database names.
|
|
|
|
*
|
|
|
|
* Originally by
|
|
|
|
* B. Palmer, bpalmer@crimelabs.net 1-17-2001
|
2007-12-11 03:31:49 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* contrib/oid2name/oid2name.c
|
2001-01-24 01:41:25 +01:00
|
|
|
*/
|
2001-10-03 00:38:43 +02:00
|
|
|
#include "postgres_fe.h"
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2018-04-08 19:59:52 +02:00
|
|
|
#include "catalog/pg_class_d.h"
|
2020-08-10 18:22:54 +02:00
|
|
|
#include "common/connect.h"
|
2019-09-06 07:00:13 +02:00
|
|
|
#include "common/logging.h"
|
Remove arbitrary restrictions on password length.
This patch started out with the goal of harmonizing various arbitrary
limits on password length, but after awhile a better idea emerged:
let's just get rid of those fixed limits.
recv_password_packet() has an arbitrary limit on the packet size,
which we don't really need, so just drop it. (Note that this doesn't
really affect anything for MD5 or SCRAM password verification, since
those will hash the user's password to something shorter anyway.
It does matter for auth methods that require a cleartext password.)
Likewise remove the arbitrary error condition in pg_saslprep().
The remaining limits are mostly in client-side code that prompts
for passwords. To improve those, refactor simple_prompt() so that
it allocates its own result buffer that can be made as big as
necessary. Actually, it proves best to make a separate routine
pg_get_line() that has essentially the semantics of fgets(), except
that it allocates a suitable result buffer and hence will never
return a truncated line. (pg_get_line has a lot of potential
applications to replace randomly-sized fgets buffers elsewhere,
but I'll leave that for another patch.)
I built pg_get_line() atop stringinfo.c, which requires moving
that code to src/common/; but that seems fine since it was a poor
fit for src/port/ anyway.
This patch is mostly mine, but it owes a good deal to Nathan Bossart
who pressed for a solution to the password length problem and
created a predecessor patch. Also thanks to Peter Eisentraut and
Stephen Frost for ideas and discussion.
Discussion: https://postgr.es/m/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
2020-09-04 02:09:18 +02:00
|
|
|
#include "common/string.h"
|
2019-10-23 05:56:22 +02:00
|
|
|
#include "getopt_long.h"
|
2001-01-24 01:41:25 +01:00
|
|
|
#include "libpq-fe.h"
|
2014-02-15 20:31:30 +01:00
|
|
|
#include "pg_getopt.h"
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* an extensible array to keep track of elements to show */
|
|
|
|
typedef struct
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
char **array;
|
|
|
|
int num;
|
|
|
|
int alloc;
|
2009-06-11 16:49:15 +02:00
|
|
|
} eary;
|
2004-09-17 23:14:19 +02:00
|
|
|
|
2001-01-24 01:41:25 +01:00
|
|
|
/* these are the opts structures for command line params */
|
2001-03-22 05:01:46 +01:00
|
|
|
struct options
|
|
|
|
{
|
2004-09-17 23:14:19 +02:00
|
|
|
eary *tables;
|
|
|
|
eary *oids;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
eary *filenumbers;
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
bool quiet;
|
|
|
|
bool systables;
|
|
|
|
bool indexes;
|
|
|
|
bool nodb;
|
|
|
|
bool extended;
|
|
|
|
bool tablespaces;
|
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
char *dbname;
|
|
|
|
char *hostname;
|
|
|
|
char *port;
|
|
|
|
char *username;
|
2012-07-04 21:39:33 +02:00
|
|
|
const char *progname;
|
2001-01-24 01:41:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* function prototypes */
|
2009-02-27 10:30:21 +01:00
|
|
|
static void help(const char *progname);
|
2022-09-22 22:59:20 +02:00
|
|
|
void get_opts(int argc, char **argv, struct options *my_opts);
|
2009-06-11 16:49:15 +02:00
|
|
|
void add_one_elt(char *eltname, eary *eary);
|
|
|
|
char *get_comma_elts(eary *eary);
|
2022-09-22 22:59:20 +02:00
|
|
|
PGconn *sql_conn(struct options *my_opts);
|
|
|
|
int sql_exec(PGconn *conn, const char *todo, bool quiet);
|
|
|
|
void sql_exec_dumpalldbs(PGconn *conn, struct options *opts);
|
|
|
|
void sql_exec_dumpalltables(PGconn *conn, struct options *opts);
|
|
|
|
void sql_exec_searchtables(PGconn *conn, struct options *opts);
|
|
|
|
void sql_exec_dumpalltbspc(PGconn *conn, struct options *opts);
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2003-03-10 23:28:22 +01:00
|
|
|
/* function to parse command line options and check for some usage errors. */
|
2001-03-22 05:01:46 +01:00
|
|
|
void
|
2017-06-21 20:39:04 +02:00
|
|
|
get_opts(int argc, char **argv, struct options *my_opts)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2018-08-28 14:33:32 +02:00
|
|
|
static struct option long_options[] = {
|
|
|
|
{"dbname", required_argument, NULL, 'd'},
|
|
|
|
{"host", required_argument, NULL, 'h'},
|
|
|
|
{"host", required_argument, NULL, 'H'}, /* deprecated */
|
|
|
|
{"filenode", required_argument, NULL, 'f'},
|
|
|
|
{"indexes", no_argument, NULL, 'i'},
|
|
|
|
{"oid", required_argument, NULL, 'o'},
|
|
|
|
{"port", required_argument, NULL, 'p'},
|
|
|
|
{"quiet", no_argument, NULL, 'q'},
|
|
|
|
{"tablespaces", no_argument, NULL, 's'},
|
|
|
|
{"system-objects", no_argument, NULL, 'S'},
|
|
|
|
{"table", required_argument, NULL, 't'},
|
|
|
|
{"username", required_argument, NULL, 'U'},
|
|
|
|
{"version", no_argument, NULL, 'V'},
|
|
|
|
{"extended", no_argument, NULL, 'x'},
|
|
|
|
{"help", no_argument, NULL, '?'},
|
|
|
|
{NULL, 0, NULL, 0}
|
|
|
|
};
|
|
|
|
|
2001-11-15 19:40:52 +01:00
|
|
|
int c;
|
2009-02-27 10:30:21 +01:00
|
|
|
const char *progname;
|
2018-08-28 14:33:32 +02:00
|
|
|
int optindex;
|
2009-02-27 10:30:21 +01:00
|
|
|
|
2019-09-06 07:00:13 +02:00
|
|
|
pg_logging_init(argv[0]);
|
2009-02-27 10:30:21 +01:00
|
|
|
progname = get_progname(argv[0]);
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* set the defaults */
|
2004-09-17 23:14:19 +02:00
|
|
|
my_opts->quiet = false;
|
|
|
|
my_opts->systables = false;
|
|
|
|
my_opts->indexes = false;
|
|
|
|
my_opts->nodb = false;
|
|
|
|
my_opts->extended = false;
|
|
|
|
my_opts->tablespaces = false;
|
2004-12-02 07:14:50 +01:00
|
|
|
my_opts->dbname = NULL;
|
|
|
|
my_opts->hostname = NULL;
|
|
|
|
my_opts->port = NULL;
|
|
|
|
my_opts->username = NULL;
|
2012-07-04 21:39:33 +02:00
|
|
|
my_opts->progname = progname;
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2009-02-27 10:30:21 +01:00
|
|
|
if (argc > 1)
|
|
|
|
{
|
|
|
|
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
|
|
|
|
{
|
|
|
|
help(progname);
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
|
|
|
|
{
|
|
|
|
puts("oid2name (PostgreSQL) " PG_VERSION);
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* get opts */
|
2018-08-28 14:33:32 +02:00
|
|
|
while ((c = getopt_long(argc, argv, "d:f:h:H:io:p:qsSt:U:x", long_options, &optindex)) != -1)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
switch (c)
|
|
|
|
{
|
|
|
|
/* specify the database */
|
|
|
|
case 'd':
|
2012-10-02 21:35:10 +02:00
|
|
|
my_opts->dbname = pg_strdup(optarg);
|
2001-03-22 05:01:46 +01:00
|
|
|
break;
|
|
|
|
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
/* specify one filenumber to show */
|
2004-09-17 23:14:19 +02:00
|
|
|
case 'f':
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
add_one_elt(optarg, my_opts->filenumbers);
|
2001-03-22 05:01:46 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* host to connect to */
|
2018-08-28 14:33:32 +02:00
|
|
|
case 'H': /* deprecated */
|
|
|
|
case 'h':
|
2012-10-02 21:35:10 +02:00
|
|
|
my_opts->hostname = pg_strdup(optarg);
|
2001-03-22 05:01:46 +01:00
|
|
|
break;
|
|
|
|
|
2018-08-28 14:33:32 +02:00
|
|
|
/* also display indexes */
|
|
|
|
case 'i':
|
|
|
|
my_opts->indexes = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* specify one Oid to show */
|
|
|
|
case 'o':
|
|
|
|
add_one_elt(optarg, my_opts->oids);
|
|
|
|
break;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* port to connect to on remote host */
|
|
|
|
case 'p':
|
2012-10-02 21:35:10 +02:00
|
|
|
my_opts->port = pg_strdup(optarg);
|
2001-03-22 05:01:46 +01:00
|
|
|
break;
|
|
|
|
|
2018-08-28 14:33:32 +02:00
|
|
|
/* don't show headers */
|
|
|
|
case 'q':
|
|
|
|
my_opts->quiet = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* dump tablespaces only */
|
|
|
|
case 's':
|
|
|
|
my_opts->tablespaces = true;
|
2001-03-22 05:01:46 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* display system tables */
|
2004-09-17 23:14:19 +02:00
|
|
|
case 'S':
|
|
|
|
my_opts->systables = true;
|
|
|
|
break;
|
|
|
|
|
2018-08-28 14:33:32 +02:00
|
|
|
/* specify one tablename to show */
|
|
|
|
case 't':
|
|
|
|
add_one_elt(optarg, my_opts->tables);
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* username */
|
|
|
|
case 'U':
|
|
|
|
my_opts->username = pg_strdup(optarg);
|
2004-09-17 23:14:19 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* display extra columns */
|
2001-03-22 05:01:46 +01:00
|
|
|
case 'x':
|
2004-09-17 23:14:19 +02:00
|
|
|
my_opts->extended = true;
|
|
|
|
break;
|
|
|
|
|
2009-02-27 10:30:21 +01:00
|
|
|
default:
|
2022-04-08 20:55:14 +02:00
|
|
|
/* getopt_long already emitted a complaint */
|
|
|
|
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
|
2009-02-27 10:30:21 +01:00
|
|
|
exit(1);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
2019-08-29 16:19:35 +02:00
|
|
|
|
|
|
|
if (optind < argc)
|
|
|
|
{
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error("too many command-line arguments (first is \"%s\")",
|
|
|
|
argv[optind]);
|
|
|
|
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
|
2019-08-29 16:19:35 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2009-02-27 10:30:21 +01:00
|
|
|
static void
|
|
|
|
help(const char *progname)
|
|
|
|
{
|
|
|
|
printf("%s helps examining the file structure used by PostgreSQL.\n\n"
|
|
|
|
"Usage:\n"
|
2012-05-08 20:55:05 +02:00
|
|
|
" %s [OPTION]...\n"
|
2009-02-27 10:30:21 +01:00
|
|
|
"\nOptions:\n"
|
2018-08-28 14:33:32 +02:00
|
|
|
" -f, --filenode=FILENODE show info for table with given file node\n"
|
|
|
|
" -i, --indexes show indexes and sequences too\n"
|
|
|
|
" -o, --oid=OID show info for table with given OID\n"
|
|
|
|
" -q, --quiet quiet (don't show headers)\n"
|
|
|
|
" -s, --tablespaces show all tablespaces\n"
|
|
|
|
" -S, --system-objects show system objects too\n"
|
|
|
|
" -t, --table=TABLE show info for named table\n"
|
|
|
|
" -V, --version output version information, then exit\n"
|
|
|
|
" -x, --extended extended (show additional columns)\n"
|
|
|
|
" -?, --help show this help, then exit\n"
|
|
|
|
"\nConnection options:\n"
|
|
|
|
" -d, --dbname=DBNAME database to connect to\n"
|
|
|
|
" -h, --host=HOSTNAME database server host or socket directory\n"
|
2023-03-02 14:36:37 +01:00
|
|
|
" -H (same as -h, deprecated)\n"
|
2018-08-28 14:33:32 +02:00
|
|
|
" -p, --port=PORT database server port number\n"
|
|
|
|
" -U, --username=USERNAME connect as specified database user\n"
|
2009-02-27 10:30:21 +01:00
|
|
|
"\nThe default action is to show all database OIDs.\n\n"
|
2020-02-28 08:54:49 +01:00
|
|
|
"Report bugs to <%s>.\n"
|
|
|
|
"%s home page: <%s>\n",
|
|
|
|
progname, progname, PACKAGE_BUGREPORT, PACKAGE_NAME, PACKAGE_URL);
|
2009-02-27 10:30:21 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/*
|
|
|
|
* add_one_elt
|
|
|
|
*
|
|
|
|
* Add one element to a (possibly empty) eary struct.
|
|
|
|
*/
|
|
|
|
void
|
2009-06-11 16:49:15 +02:00
|
|
|
add_one_elt(char *eltname, eary *eary)
|
2004-09-17 23:14:19 +02:00
|
|
|
{
|
|
|
|
if (eary->alloc == 0)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
eary ->alloc = 8;
|
2012-10-02 21:35:10 +02:00
|
|
|
eary ->array = (char **) pg_malloc(8 * sizeof(char *));
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
2004-09-17 23:14:19 +02:00
|
|
|
else if (eary->num >= eary->alloc)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
eary ->alloc *= 2;
|
2012-10-02 23:31:40 +02:00
|
|
|
eary ->array = (char **) pg_realloc(eary->array,
|
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
|
|
|
eary->alloc * sizeof(char *));
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2012-10-02 21:35:10 +02:00
|
|
|
eary ->array[eary->num] = pg_strdup(eltname);
|
2009-06-11 16:49:15 +02:00
|
|
|
eary ->num++;
|
2004-09-17 23:14:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get_comma_elts
|
|
|
|
*
|
|
|
|
* Return the elements of an eary as a (freshly allocated) single string, in
|
|
|
|
* single quotes, separated by commas and properly escaped for insertion in an
|
|
|
|
* SQL statement.
|
|
|
|
*/
|
|
|
|
char *
|
2009-06-11 16:49:15 +02:00
|
|
|
get_comma_elts(eary *eary)
|
2004-09-17 23:14:19 +02:00
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
char *ret,
|
|
|
|
*ptr;
|
|
|
|
int i,
|
|
|
|
length = 0;
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
if (eary->num == 0)
|
2012-10-02 21:35:10 +02:00
|
|
|
return pg_strdup("");
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* PQescapeString wants 2 * length + 1 bytes of breath space. Add two
|
|
|
|
* chars per element for the single quotes and one for the comma.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < eary->num; i++)
|
|
|
|
length += strlen(eary->array[i]);
|
|
|
|
|
2012-10-02 21:35:10 +02:00
|
|
|
ret = (char *) pg_malloc(length * 2 + 4 * eary->num);
|
2004-09-17 23:14:19 +02:00
|
|
|
ptr = ret;
|
|
|
|
|
|
|
|
for (i = 0; i < eary->num; i++)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2004-09-17 23:14:19 +02:00
|
|
|
if (i != 0)
|
|
|
|
sprintf(ptr++, ",");
|
|
|
|
sprintf(ptr++, "'");
|
|
|
|
ptr += PQescapeString(ptr, eary->array[i], strlen(eary->array[i]));
|
|
|
|
sprintf(ptr++, "'");
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* establish connection with database. */
|
|
|
|
PGconn *
|
2017-06-21 20:39:04 +02:00
|
|
|
sql_conn(struct options *my_opts)
|
2004-09-17 23:14:19 +02:00
|
|
|
{
|
|
|
|
PGconn *conn;
|
Remove arbitrary restrictions on password length.
This patch started out with the goal of harmonizing various arbitrary
limits on password length, but after awhile a better idea emerged:
let's just get rid of those fixed limits.
recv_password_packet() has an arbitrary limit on the packet size,
which we don't really need, so just drop it. (Note that this doesn't
really affect anything for MD5 or SCRAM password verification, since
those will hash the user's password to something shorter anyway.
It does matter for auth methods that require a cleartext password.)
Likewise remove the arbitrary error condition in pg_saslprep().
The remaining limits are mostly in client-side code that prompts
for passwords. To improve those, refactor simple_prompt() so that
it allocates its own result buffer that can be made as big as
necessary. Actually, it proves best to make a separate routine
pg_get_line() that has essentially the semantics of fgets(), except
that it allocates a suitable result buffer and hence will never
return a truncated line. (pg_get_line has a lot of potential
applications to replace randomly-sized fgets buffers elsewhere,
but I'll leave that for another patch.)
I built pg_get_line() atop stringinfo.c, which requires moving
that code to src/common/; but that seems fine since it was a poor
fit for src/port/ anyway.
This patch is mostly mine, but it owes a good deal to Nathan Bossart
who pressed for a solution to the password length problem and
created a predecessor patch. Also thanks to Peter Eisentraut and
Stephen Frost for ideas and discussion.
Discussion: https://postgr.es/m/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
2020-09-04 02:09:18 +02:00
|
|
|
char *password = NULL;
|
2007-12-11 03:31:49 +01:00
|
|
|
bool new_pass;
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
PGresult *res;
|
2004-09-17 23:14:19 +02:00
|
|
|
|
2007-12-11 03:31:49 +01:00
|
|
|
/*
|
|
|
|
* Start the connection. Loop until we have a password if requested by
|
|
|
|
* backend.
|
|
|
|
*/
|
|
|
|
do
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2012-07-04 21:39:33 +02:00
|
|
|
#define PARAMS_ARRAY_SIZE 7
|
|
|
|
|
|
|
|
const char *keywords[PARAMS_ARRAY_SIZE];
|
|
|
|
const char *values[PARAMS_ARRAY_SIZE];
|
|
|
|
|
|
|
|
keywords[0] = "host";
|
|
|
|
values[0] = my_opts->hostname;
|
|
|
|
keywords[1] = "port";
|
|
|
|
values[1] = my_opts->port;
|
|
|
|
keywords[2] = "user";
|
|
|
|
values[2] = my_opts->username;
|
|
|
|
keywords[3] = "password";
|
Remove arbitrary restrictions on password length.
This patch started out with the goal of harmonizing various arbitrary
limits on password length, but after awhile a better idea emerged:
let's just get rid of those fixed limits.
recv_password_packet() has an arbitrary limit on the packet size,
which we don't really need, so just drop it. (Note that this doesn't
really affect anything for MD5 or SCRAM password verification, since
those will hash the user's password to something shorter anyway.
It does matter for auth methods that require a cleartext password.)
Likewise remove the arbitrary error condition in pg_saslprep().
The remaining limits are mostly in client-side code that prompts
for passwords. To improve those, refactor simple_prompt() so that
it allocates its own result buffer that can be made as big as
necessary. Actually, it proves best to make a separate routine
pg_get_line() that has essentially the semantics of fgets(), except
that it allocates a suitable result buffer and hence will never
return a truncated line. (pg_get_line has a lot of potential
applications to replace randomly-sized fgets buffers elsewhere,
but I'll leave that for another patch.)
I built pg_get_line() atop stringinfo.c, which requires moving
that code to src/common/; but that seems fine since it was a poor
fit for src/port/ anyway.
This patch is mostly mine, but it owes a good deal to Nathan Bossart
who pressed for a solution to the password length problem and
created a predecessor patch. Also thanks to Peter Eisentraut and
Stephen Frost for ideas and discussion.
Discussion: https://postgr.es/m/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
2020-09-04 02:09:18 +02:00
|
|
|
values[3] = password;
|
2012-07-04 21:39:33 +02:00
|
|
|
keywords[4] = "dbname";
|
|
|
|
values[4] = my_opts->dbname;
|
|
|
|
keywords[5] = "fallback_application_name";
|
|
|
|
values[5] = my_opts->progname;
|
|
|
|
keywords[6] = NULL;
|
|
|
|
values[6] = NULL;
|
|
|
|
|
2007-12-11 03:31:49 +01:00
|
|
|
new_pass = false;
|
2012-07-04 21:39:33 +02:00
|
|
|
conn = PQconnectdbParams(keywords, values, true);
|
|
|
|
|
2007-12-11 03:31:49 +01:00
|
|
|
if (!conn)
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_fatal("could not connect to database %s",
|
|
|
|
my_opts->dbname);
|
2007-12-11 03:31:49 +01:00
|
|
|
|
|
|
|
if (PQstatus(conn) == CONNECTION_BAD &&
|
|
|
|
PQconnectionNeedsPassword(conn) &&
|
Remove arbitrary restrictions on password length.
This patch started out with the goal of harmonizing various arbitrary
limits on password length, but after awhile a better idea emerged:
let's just get rid of those fixed limits.
recv_password_packet() has an arbitrary limit on the packet size,
which we don't really need, so just drop it. (Note that this doesn't
really affect anything for MD5 or SCRAM password verification, since
those will hash the user's password to something shorter anyway.
It does matter for auth methods that require a cleartext password.)
Likewise remove the arbitrary error condition in pg_saslprep().
The remaining limits are mostly in client-side code that prompts
for passwords. To improve those, refactor simple_prompt() so that
it allocates its own result buffer that can be made as big as
necessary. Actually, it proves best to make a separate routine
pg_get_line() that has essentially the semantics of fgets(), except
that it allocates a suitable result buffer and hence will never
return a truncated line. (pg_get_line has a lot of potential
applications to replace randomly-sized fgets buffers elsewhere,
but I'll leave that for another patch.)
I built pg_get_line() atop stringinfo.c, which requires moving
that code to src/common/; but that seems fine since it was a poor
fit for src/port/ anyway.
This patch is mostly mine, but it owes a good deal to Nathan Bossart
who pressed for a solution to the password length problem and
created a predecessor patch. Also thanks to Peter Eisentraut and
Stephen Frost for ideas and discussion.
Discussion: https://postgr.es/m/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
2020-09-04 02:09:18 +02:00
|
|
|
!password)
|
2007-12-11 03:31:49 +01:00
|
|
|
{
|
|
|
|
PQfinish(conn);
|
Remove arbitrary restrictions on password length.
This patch started out with the goal of harmonizing various arbitrary
limits on password length, but after awhile a better idea emerged:
let's just get rid of those fixed limits.
recv_password_packet() has an arbitrary limit on the packet size,
which we don't really need, so just drop it. (Note that this doesn't
really affect anything for MD5 or SCRAM password verification, since
those will hash the user's password to something shorter anyway.
It does matter for auth methods that require a cleartext password.)
Likewise remove the arbitrary error condition in pg_saslprep().
The remaining limits are mostly in client-side code that prompts
for passwords. To improve those, refactor simple_prompt() so that
it allocates its own result buffer that can be made as big as
necessary. Actually, it proves best to make a separate routine
pg_get_line() that has essentially the semantics of fgets(), except
that it allocates a suitable result buffer and hence will never
return a truncated line. (pg_get_line has a lot of potential
applications to replace randomly-sized fgets buffers elsewhere,
but I'll leave that for another patch.)
I built pg_get_line() atop stringinfo.c, which requires moving
that code to src/common/; but that seems fine since it was a poor
fit for src/port/ anyway.
This patch is mostly mine, but it owes a good deal to Nathan Bossart
who pressed for a solution to the password length problem and
created a predecessor patch. Also thanks to Peter Eisentraut and
Stephen Frost for ideas and discussion.
Discussion: https://postgr.es/m/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
2020-09-04 02:09:18 +02:00
|
|
|
password = simple_prompt("Password: ", false);
|
2007-12-11 03:31:49 +01:00
|
|
|
new_pass = true;
|
|
|
|
}
|
|
|
|
} while (new_pass);
|
|
|
|
|
|
|
|
/* check to see that the backend connection was successfully made */
|
|
|
|
if (PQstatus(conn) == CONNECTION_BAD)
|
|
|
|
{
|
2021-01-22 22:52:31 +01:00
|
|
|
pg_log_error("%s", PQerrorMessage(conn));
|
2001-03-22 05:01:46 +01:00
|
|
|
PQfinish(conn);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
res = PQexec(conn, ALWAYS_SECURE_SEARCH_PATH_SQL);
|
|
|
|
if (PQresultStatus(res) != PGRES_TUPLES_OK)
|
|
|
|
{
|
2019-09-06 07:00:13 +02:00
|
|
|
pg_log_error("could not clear search_path: %s",
|
|
|
|
PQerrorMessage(conn));
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
PQclear(res);
|
|
|
|
PQfinish(conn);
|
2022-04-08 20:55:14 +02:00
|
|
|
exit(1);
|
Empty search_path in Autovacuum and non-psql/pgbench clients.
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* return the conn if good */
|
|
|
|
return conn;
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/*
|
|
|
|
* Actual code to make call to the database and print the output data.
|
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
int
|
2004-09-17 23:14:19 +02:00
|
|
|
sql_exec(PGconn *conn, const char *todo, bool quiet)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
PGresult *res;
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
int nfields;
|
|
|
|
int nrows;
|
2005-10-15 04:49:52 +02:00
|
|
|
int i,
|
|
|
|
j,
|
|
|
|
l;
|
2004-09-17 23:14:19 +02:00
|
|
|
int *length;
|
|
|
|
char *pad;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
|
|
|
/* make the call */
|
|
|
|
res = PQexec(conn, todo);
|
|
|
|
|
|
|
|
/* check and deal with errors */
|
|
|
|
if (!res || PQresultStatus(res) > 2)
|
|
|
|
{
|
2019-09-06 07:00:13 +02:00
|
|
|
pg_log_error("query failed: %s", PQerrorMessage(conn));
|
2022-04-08 20:55:14 +02:00
|
|
|
pg_log_error_detail("Query was: %s", todo);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
|
|
|
PQclear(res);
|
|
|
|
PQfinish(conn);
|
2022-04-08 20:55:14 +02:00
|
|
|
exit(1);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* get the number of fields */
|
2004-09-17 23:14:19 +02:00
|
|
|
nrows = PQntuples(res);
|
|
|
|
nfields = PQnfields(res);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* for each field, get the needed width */
|
2012-10-02 21:35:10 +02:00
|
|
|
length = (int *) pg_malloc(sizeof(int) * nfields);
|
2004-09-17 23:14:19 +02:00
|
|
|
for (j = 0; j < nfields; j++)
|
|
|
|
length[j] = strlen(PQfname(res, j));
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
for (i = 0; i < nrows; i++)
|
|
|
|
{
|
|
|
|
for (j = 0; j < nfields; j++)
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
l = strlen(PQgetvalue(res, i, j));
|
2004-09-17 23:14:19 +02:00
|
|
|
if (l > length[j])
|
|
|
|
length[j] = strlen(PQgetvalue(res, i, j));
|
|
|
|
}
|
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* print a header */
|
|
|
|
if (!quiet)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2004-09-17 23:14:19 +02:00
|
|
|
for (j = 0, l = 0; j < nfields; j++)
|
|
|
|
{
|
|
|
|
fprintf(stdout, "%*s", length[j] + 2, PQfname(res, j));
|
|
|
|
l += length[j] + 2;
|
|
|
|
}
|
|
|
|
fprintf(stdout, "\n");
|
2012-10-02 21:35:10 +02:00
|
|
|
pad = (char *) pg_malloc(l + 1);
|
2022-07-01 00:16:38 +02:00
|
|
|
memset(pad, '-', l);
|
2004-09-17 23:14:19 +02:00
|
|
|
pad[l] = '\0';
|
|
|
|
fprintf(stdout, "%s\n", pad);
|
|
|
|
free(pad);
|
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* for each row, dump the information */
|
|
|
|
for (i = 0; i < nrows; i++)
|
|
|
|
{
|
|
|
|
for (j = 0; j < nfields; j++)
|
|
|
|
fprintf(stdout, "%*s", length[j] + 2, PQgetvalue(res, i, j));
|
|
|
|
fprintf(stdout, "\n");
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* cleanup */
|
2001-03-22 05:01:46 +01:00
|
|
|
PQclear(res);
|
2004-09-17 23:14:19 +02:00
|
|
|
free(length);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
|
|
|
return 0;
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Dump all databases. There are no system objects to worry about.
|
2004-09-17 23:14:19 +02:00
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
void
|
2017-06-21 20:39:04 +02:00
|
|
|
sql_exec_dumpalldbs(PGconn *conn, struct options *opts)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2002-03-05 06:54:07 +01:00
|
|
|
char todo[1024];
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/* get the oid and database name from the system pg_database table */
|
2004-11-05 20:17:13 +01:00
|
|
|
snprintf(todo, sizeof(todo),
|
|
|
|
"SELECT d.oid AS \"Oid\", datname AS \"Database Name\", "
|
2010-02-26 03:01:40 +01:00
|
|
|
"spcname AS \"Tablespace\" FROM pg_catalog.pg_database d JOIN pg_catalog.pg_tablespace t ON "
|
2004-09-17 23:14:19 +02:00
|
|
|
"(dattablespace = t.oid) ORDER BY 2");
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
sql_exec(conn, todo, opts->quiet);
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
/*
|
2004-09-17 23:14:19 +02:00
|
|
|
* Dump all tables, indexes and sequences in the current database.
|
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
void
|
2017-06-21 20:39:04 +02:00
|
|
|
sql_exec_dumpalltables(PGconn *conn, struct options *opts)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2002-03-05 06:54:07 +01:00
|
|
|
char todo[1024];
|
2004-09-17 23:14:19 +02:00
|
|
|
char *addfields = ",c.oid AS \"Oid\", nspname AS \"Schema\", spcname as \"Tablespace\" ";
|
|
|
|
|
2004-11-05 20:17:13 +01:00
|
|
|
snprintf(todo, sizeof(todo),
|
2010-02-26 03:01:40 +01:00
|
|
|
"SELECT pg_catalog.pg_relation_filenode(c.oid) as \"Filenode\", relname as \"Table Name\" %s "
|
2017-03-10 05:36:44 +01:00
|
|
|
"FROM pg_catalog.pg_class c "
|
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
|
|
|
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace "
|
2010-02-26 03:01:40 +01:00
|
|
|
" LEFT JOIN pg_catalog.pg_database d ON d.datname = pg_catalog.current_database(),"
|
2004-09-17 23:14:19 +02:00
|
|
|
" pg_catalog.pg_tablespace t "
|
2017-03-10 05:36:44 +01:00
|
|
|
"WHERE relkind IN (" CppAsString2(RELKIND_RELATION) ","
|
|
|
|
CppAsString2(RELKIND_MATVIEW) "%s%s) AND "
|
2004-09-17 23:14:19 +02:00
|
|
|
" %s"
|
|
|
|
" t.oid = CASE"
|
|
|
|
" WHEN reltablespace <> 0 THEN reltablespace"
|
2004-11-05 20:17:13 +01:00
|
|
|
" ELSE dattablespace"
|
2004-09-17 23:14:19 +02:00
|
|
|
" END "
|
|
|
|
"ORDER BY relname",
|
|
|
|
opts->extended ? addfields : "",
|
2017-03-10 05:36:44 +01:00
|
|
|
opts->indexes ? "," CppAsString2(RELKIND_INDEX) "," CppAsString2(RELKIND_SEQUENCE) : "",
|
|
|
|
opts->systables ? "," CppAsString2(RELKIND_TOASTVALUE) : "",
|
2007-07-26 00:16:18 +02:00
|
|
|
opts->systables ? "" : "n.nspname NOT IN ('pg_catalog', 'information_schema') AND n.nspname !~ '^pg_toast' AND");
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
sql_exec(conn, todo, opts->quiet);
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/*
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
* Show oid, filenumber, name, schema and tablespace for each of the
|
2004-09-17 23:14:19 +02:00
|
|
|
* given objects in the current database.
|
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
void
|
2017-06-21 20:39:04 +02:00
|
|
|
sql_exec_searchtables(PGconn *conn, struct options *opts)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2004-09-17 23:14:19 +02:00
|
|
|
char *todo;
|
2005-10-15 04:49:52 +02:00
|
|
|
char *qualifiers,
|
|
|
|
*ptr;
|
|
|
|
char *comma_oids,
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
*comma_filenumbers,
|
2005-10-15 04:49:52 +02:00
|
|
|
*comma_tables;
|
2004-09-17 23:14:19 +02:00
|
|
|
bool written = false;
|
|
|
|
char *addfields = ",c.oid AS \"Oid\", nspname AS \"Schema\", spcname as \"Tablespace\" ";
|
|
|
|
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
/* get tables qualifiers, whether names, filenumbers, or OIDs */
|
2004-09-17 23:14:19 +02:00
|
|
|
comma_oids = get_comma_elts(opts->oids);
|
|
|
|
comma_tables = get_comma_elts(opts->tables);
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
comma_filenumbers = get_comma_elts(opts->filenumbers);
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
/* 80 extra chars for SQL expression */
|
2012-10-02 21:35:10 +02:00
|
|
|
qualifiers = (char *) pg_malloc(strlen(comma_oids) + strlen(comma_tables) +
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
strlen(comma_filenumbers) + 80);
|
2004-09-17 23:14:19 +02:00
|
|
|
ptr = qualifiers;
|
|
|
|
|
|
|
|
if (opts->oids->num > 0)
|
|
|
|
{
|
|
|
|
ptr += sprintf(ptr, "c.oid IN (%s)", comma_oids);
|
|
|
|
written = true;
|
|
|
|
}
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
if (opts->filenumbers->num > 0)
|
2004-09-17 23:14:19 +02:00
|
|
|
{
|
|
|
|
if (written)
|
|
|
|
ptr += sprintf(ptr, " OR ");
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
ptr += sprintf(ptr, "pg_catalog.pg_relation_filenode(c.oid) IN (%s)",
|
|
|
|
comma_filenumbers);
|
2004-09-17 23:14:19 +02:00
|
|
|
written = true;
|
|
|
|
}
|
|
|
|
if (opts->tables->num > 0)
|
|
|
|
{
|
|
|
|
if (written)
|
|
|
|
ptr += sprintf(ptr, " OR ");
|
|
|
|
sprintf(ptr, "c.relname ~~ ANY (ARRAY[%s])", comma_tables);
|
|
|
|
}
|
|
|
|
free(comma_oids);
|
|
|
|
free(comma_tables);
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
free(comma_filenumbers);
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
/* now build the query */
|
2020-01-30 17:42:14 +01:00
|
|
|
todo = psprintf("SELECT pg_catalog.pg_relation_filenode(c.oid) as \"Filenode\", relname as \"Table Name\" %s\n"
|
2017-04-14 05:47:46 +02:00
|
|
|
"FROM pg_catalog.pg_class c\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
|
|
|
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
" LEFT JOIN pg_catalog.pg_database d ON d.datname = pg_catalog.current_database(),\n"
|
2017-04-14 05:47:46 +02:00
|
|
|
" pg_catalog.pg_tablespace t\n"
|
2017-03-10 05:36:44 +01:00
|
|
|
"WHERE relkind IN (" CppAsString2(RELKIND_RELATION) ","
|
|
|
|
CppAsString2(RELKIND_MATVIEW) ","
|
|
|
|
CppAsString2(RELKIND_INDEX) ","
|
|
|
|
CppAsString2(RELKIND_SEQUENCE) ","
|
2017-04-14 05:47:46 +02:00
|
|
|
CppAsString2(RELKIND_TOASTVALUE) ") AND\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
" t.oid = CASE\n"
|
2017-06-21 20:39:04 +02:00
|
|
|
" WHEN reltablespace <> 0 THEN reltablespace\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
" ELSE dattablespace\n"
|
2017-04-14 05:47:46 +02:00
|
|
|
" END AND\n"
|
|
|
|
" (%s)\n"
|
2014-05-06 18:12:18 +02:00
|
|
|
"ORDER BY relname\n",
|
|
|
|
opts->extended ? addfields : "",
|
|
|
|
qualifiers);
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
free(qualifiers);
|
|
|
|
|
|
|
|
sql_exec(conn, todo, opts->quiet);
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
void
|
2017-06-21 20:39:04 +02:00
|
|
|
sql_exec_dumpalltbspc(PGconn *conn, struct options *opts)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
char todo[1024];
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2004-11-05 20:17:13 +01:00
|
|
|
snprintf(todo, sizeof(todo),
|
|
|
|
"SELECT oid AS \"Oid\", spcname as \"Tablespace Name\"\n"
|
2010-02-07 21:48:13 +01:00
|
|
|
"FROM pg_catalog.pg_tablespace");
|
2001-01-24 01:41:25 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
sql_exec(conn, todo, opts->quiet);
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
int
|
|
|
|
main(int argc, char **argv)
|
2001-01-24 01:41:25 +01:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
struct options *my_opts;
|
|
|
|
PGconn *pgconn;
|
|
|
|
|
2012-10-02 21:35:10 +02:00
|
|
|
my_opts = (struct options *) pg_malloc(sizeof(struct options));
|
2004-09-17 23:14:19 +02:00
|
|
|
|
2012-10-02 21:35:10 +02:00
|
|
|
my_opts->oids = (eary *) pg_malloc(sizeof(eary));
|
|
|
|
my_opts->tables = (eary *) pg_malloc(sizeof(eary));
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
my_opts->filenumbers = (eary *) pg_malloc(sizeof(eary));
|
2004-09-17 23:14:19 +02:00
|
|
|
|
|
|
|
my_opts->oids->num = my_opts->oids->alloc = 0;
|
|
|
|
my_opts->tables->num = my_opts->tables->alloc = 0;
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
my_opts->filenumbers->num = my_opts->filenumbers->alloc = 0;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
|
|
|
/* parse the opts */
|
|
|
|
get_opts(argc, argv, my_opts);
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
if (my_opts->dbname == NULL)
|
|
|
|
{
|
2005-06-21 06:02:34 +02:00
|
|
|
my_opts->dbname = "postgres";
|
2004-09-17 23:14:19 +02:00
|
|
|
my_opts->nodb = true;
|
|
|
|
}
|
|
|
|
pgconn = sql_conn(my_opts);
|
|
|
|
|
|
|
|
/* display only tablespaces */
|
|
|
|
if (my_opts->tablespaces)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2002-06-12 23:09:09 +02:00
|
|
|
if (!my_opts->quiet)
|
2004-09-17 23:14:19 +02:00
|
|
|
printf("All tablespaces:\n");
|
|
|
|
sql_exec_dumpalltbspc(pgconn, my_opts);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
PQfinish(pgconn);
|
|
|
|
exit(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* display the given elements in the database */
|
|
|
|
if (my_opts->oids->num > 0 ||
|
|
|
|
my_opts->tables->num > 0 ||
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
my_opts->filenumbers->num > 0)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2002-06-12 23:09:09 +02:00
|
|
|
if (!my_opts->quiet)
|
2004-09-17 23:14:19 +02:00
|
|
|
printf("From database \"%s\":\n", my_opts->dbname);
|
|
|
|
sql_exec_searchtables(pgconn, my_opts);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
PQfinish(pgconn);
|
|
|
|
exit(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* no elements given; dump the given database */
|
|
|
|
if (my_opts->dbname && !my_opts->nodb)
|
2001-03-22 05:01:46 +01:00
|
|
|
{
|
2002-06-12 23:09:09 +02:00
|
|
|
if (!my_opts->quiet)
|
2004-09-17 23:14:19 +02:00
|
|
|
printf("From database \"%s\":\n", my_opts->dbname);
|
|
|
|
sql_exec_dumpalltables(pgconn, my_opts);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
PQfinish(pgconn);
|
|
|
|
exit(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
}
|
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
/* no database either; dump all databases */
|
2002-06-12 23:09:09 +02:00
|
|
|
if (!my_opts->quiet)
|
|
|
|
printf("All databases:\n");
|
2004-09-17 23:14:19 +02:00
|
|
|
sql_exec_dumpalldbs(pgconn, my_opts);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2004-09-17 23:14:19 +02:00
|
|
|
PQfinish(pgconn);
|
2007-07-16 00:54:21 +02:00
|
|
|
return 0;
|
2001-01-24 01:41:25 +01:00
|
|
|
}
|