|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* prepare.h
|
|
|
|
|
* PREPARE, EXECUTE and DEALLOCATE commands, and prepared-stmt storage
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2002-2020, PostgreSQL Global Development Group
|
|
|
|
|
*
|
|
|
|
|
* src/include/commands/prepare.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PREPARE_H
|
|
|
|
|
#define PREPARE_H
|
|
|
|
|
|
|
|
|
|
#include "commands/explain.h"
|
|
|
|
|
#include "datatype/timestamp.h"
|
|
|
|
|
#include "utils/plancache.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The data structure representing a prepared statement. This is now just
|
|
|
|
|
* a thin veneer over a plancache entry --- the main addition is that of
|
|
|
|
|
* a name.
|
|
|
|
|
*
|
|
|
|
|
* Note: all subsidiary storage lives in the referenced plancache entry.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
/* dynahash.c requires key to be first field */
|
|
|
|
|
char stmt_name[NAMEDATALEN];
|
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
8 years ago
|
|
|
CachedPlanSource *plansource; /* the actual cached plan */
|
|
|
|
|
bool from_sql; /* prepared via SQL, not FE/BE protocol? */
|
|
|
|
|
TimestampTz prepare_time; /* the time when the stmt was prepared */
|
|
|
|
|
} PreparedStatement;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Utility statements PREPARE, EXECUTE, DEALLOCATE, EXPLAIN EXECUTE */
|
|
|
|
|
extern void PrepareQuery(ParseState *pstate, PrepareStmt *stmt,
|
|
|
|
|
int stmt_location, int stmt_len);
|
|
|
|
|
extern void ExecuteQuery(ParseState *pstate,
|
|
|
|
|
ExecuteStmt *stmt, IntoClause *intoClause,
|
|
|
|
|
ParamListInfo params,
|
|
|
|
|
DestReceiver *dest, char *completionTag);
|
|
|
|
|
extern void DeallocateQuery(DeallocateStmt *stmt);
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
14 years ago
|
|
|
extern void ExplainExecuteQuery(ExecuteStmt *execstmt, IntoClause *into,
|
|
|
|
|
ExplainState *es, const char *queryString,
|
|
|
|
|
ParamListInfo params, QueryEnvironment *queryEnv);
|
|
|
|
|
|
|
|
|
|
/* Low-level access to stored prepared statements */
|
|
|
|
|
extern void StorePreparedStatement(const char *stmt_name,
|
|
|
|
|
CachedPlanSource *plansource,
|
|
|
|
|
bool from_sql);
|
|
|
|
|
extern PreparedStatement *FetchPreparedStatement(const char *stmt_name,
|
|
|
|
|
bool throwError);
|
|
|
|
|
extern void DropPreparedStatement(const char *stmt_name, bool showError);
|
|
|
|
|
extern TupleDesc FetchPreparedStatementResultDesc(PreparedStatement *stmt);
|
|
|
|
|
extern List *FetchPreparedStatementTargetList(PreparedStatement *stmt);
|
|
|
|
|
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
14 years ago
|
|
|
extern void DropAllPreparedStatements(void);
|
|
|
|
|
|
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
8 years ago
|
|
|
#endif /* PREPARE_H */
|
