2016-03-24 15:55:44 -04:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* String-processing utility routines for frontend code
|
|
|
|
|
*
|
2016-08-08 10:07:46 -04:00
|
|
|
* Utility functions that interpret backend output or quote strings for
|
|
|
|
|
* assorted contexts.
|
2016-03-24 15:55:44 -04:00
|
|
|
*
|
|
|
|
|
*
|
2018-01-02 23:30:12 -05:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2016-03-24 15:55:44 -04:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/include/fe_utils/string_utils.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef STRING_UTILS_H
|
|
|
|
|
#define STRING_UTILS_H
|
|
|
|
|
|
|
|
|
|
#include "libpq-fe.h"
|
|
|
|
|
#include "pqexpbuffer.h"
|
|
|
|
|
|
|
|
|
|
/* Global variables controlling behavior of fmtId() and fmtQualifiedId() */
|
|
|
|
|
extern int quote_all_identifiers;
|
|
|
|
|
extern PQExpBuffer (*getLocalPQExpBuffer) (void);
|
|
|
|
|
|
|
|
|
|
/* Functions */
|
|
|
|
|
extern const char *fmtId(const char *identifier);
|
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands.
Previously, this code blindly followed the common coding pattern of
passing PQserverVersion(AH->connection) as the server-version parameter
of fmtQualifiedId. That works as long as we have a connection; but in
pg_restore with text output, we don't. Instead we got a zero from
PQserverVersion, which fmtQualifiedId interpreted as "server is too old to
have schemas", and so the name went unqualified. That still accidentally
managed to work in many cases, which is probably why this ancient bug went
undetected for so long. It only became obvious in the wake of the changes
to force dump/restore to execute with restricted search_path.
In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server-
version behavioral dependency, and just making it schema-qualify all the
time. We no longer support pg_dump from servers old enough to need the
ability to omit schema name, let alone restoring to them. (Also, the few
callers outside pg_dump already didn't work with pre-schema servers.)
In older branches, that's not an acceptable solution, so instead just
tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify
its output regardless of server version.
Per bug #15338 from Oleg somebody. Back-patch to all supported branches.
Discussion: https://postgr.es/m/153452458706.1316.5328079417086507743@wrigleys.postgresql.org
2018-08-17 17:12:21 -04:00
|
|
|
extern const char *fmtQualifiedId(const char *schema, const char *id);
|
2016-03-24 15:55:44 -04:00
|
|
|
|
Fix assorted places in psql to print version numbers >= 10 in new style.
This is somewhat cosmetic, since as long as you know what you are looking
at, "10.0" is a serviceable substitute for "10". But there is a potential
for confusion between version numbers with minor numbers and those without
--- we don't want people asking "why is psql saying 10.0 when my server is
10.2". Therefore, back-patch as far as practical, which turns out to be
9.3. I could have redone the patch to use fprintf(stderr) in place of
psql_error(), but it seems more work than is warranted for branches that
will be EOL or nearly so by the time v10 comes out.
Although only psql seems to contain any code that needs this, I chose
to put the support function into fe_utils, since it seems likely we'll
need it in other client programs in future. (In 9.3-9.5, use dumputils.c,
the predecessor of fe_utils/string_utils.c.)
In HEAD, also fix the backend code that whines about loadable-library
version mismatch. I don't see much need to back-patch that.
2016-08-16 15:58:30 -04:00
|
|
|
extern char *formatPGVersionNumber(int version_number, bool include_minor,
|
|
|
|
|
char *buf, size_t buflen);
|
|
|
|
|
|
2016-03-24 15:55:44 -04:00
|
|
|
extern void appendStringLiteral(PQExpBuffer buf, const char *str,
|
|
|
|
|
int encoding, bool std_strings);
|
|
|
|
|
extern void appendStringLiteralConn(PQExpBuffer buf, const char *str,
|
|
|
|
|
PGconn *conn);
|
|
|
|
|
extern void appendStringLiteralDQ(PQExpBuffer buf, const char *str,
|
|
|
|
|
const char *dqprefix);
|
|
|
|
|
extern void appendByteaLiteral(PQExpBuffer buf,
|
|
|
|
|
const unsigned char *str, size_t length,
|
|
|
|
|
bool std_strings);
|
|
|
|
|
|
2016-08-08 10:07:46 -04:00
|
|
|
extern void appendShellString(PQExpBuffer buf, const char *str);
|
Allow psql variable substitution to occur in backtick command strings.
Previously, text between backquotes in a psql metacommand's arguments
was always passed to the shell literally. That considerably hobbles
the usefulness of the feature for scripting, so we'd foreseen for a long
time that we'd someday want to allow substitution of psql variables into
the shell command. IMO the addition of \if metacommands has brought us to
that point, since \if can greatly benefit from some sort of client-side
expression evaluation capability, and psql itself is not going to grow any
such thing in time for v10. Hence, this patch. It allows :VARIABLE to be
replaced by the exact contents of the named variable, while :'VARIABLE'
is replaced by the variable's contents suitably quoted to become a single
shell-command argument. (The quoting rules for that are different from
those for SQL literals, so this is a bit of an abuse of the :'VARIABLE'
notation, but I doubt anyone will be confused.)
As with other situations in psql, no substitution occurs if the word
following a colon is not a known variable name. That limits the risk of
compatibility problems for existing psql scripts; but the risk isn't zero,
so this needs to be called out in the v10 release notes.
Discussion: https://postgr.es/m/9561.1490895211@sss.pgh.pa.us
2017-04-01 21:44:54 -04:00
|
|
|
extern bool appendShellStringNoError(PQExpBuffer buf, const char *str);
|
2016-08-08 10:07:46 -04:00
|
|
|
extern void appendConnStrVal(PQExpBuffer buf, const char *str);
|
2016-08-08 10:07:46 -04:00
|
|
|
extern void appendPsqlMetaConnect(PQExpBuffer buf, const char *dbname);
|
2016-08-08 10:07:46 -04:00
|
|
|
|
2016-03-24 15:55:44 -04:00
|
|
|
extern bool parsePGArray(const char *atext, char ***itemarray, int *nitems);
|
|
|
|
|
|
2016-05-06 07:45:36 -04:00
|
|
|
extern bool appendReloptionsArray(PQExpBuffer buffer, const char *reloptions,
|
|
|
|
|
const char *prefix, int encoding, bool std_strings);
|
|
|
|
|
|
2016-03-24 15:55:44 -04:00
|
|
|
extern bool processSQLNamePattern(PGconn *conn, PQExpBuffer buf,
|
|
|
|
|
const char *pattern,
|
|
|
|
|
bool have_where, bool force_escape,
|
|
|
|
|
const char *schemavar, const char *namevar,
|
|
|
|
|
const char *altnamevar, const char *visibilityrule);
|
|
|
|
|
|
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 15:18:54 -04:00
|
|
|
#endif /* STRING_UTILS_H */
|