|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* defrem.h
|
|
|
|
|
* POSTGRES define and remove utility definitions.
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/include/commands/defrem.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef DEFREM_H
|
|
|
|
|
#define DEFREM_H
|
|
|
|
|
|
|
|
|
|
#include "nodes/parsenodes.h"
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
12 years ago
|
|
|
#include "utils/array.h"
|
|
|
|
|
|
|
|
|
|
/* commands/dropcmds.c */
|
|
|
|
|
extern void RemoveObjects(DropStmt *stmt);
|
|
|
|
|
|
|
|
|
|
/* commands/indexcmds.c */
|
Avoid pre-determining index names during CREATE TABLE LIKE parsing.
Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE
had to pre-assign names to indexes that had comments, because it made up an
explicit CommentStmt command to apply the comment and so it had to know the
name for the index. This creates bad interactions with other indexes, as
shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't
take any other indexes into account so it could choose a conflicting name.
To fix, add a field to IndexStmt that allows it to carry a comment to be
assigned to the new index. (This isn't a user-exposed feature of CREATE
INDEX, only an internal option.) Now we don't need preassignment of index
names in any situation.
I also took the opportunity to refactor DefineIndex to accept the IndexStmt
as such, rather than passing all its fields individually in a mile-long
parameter list.
Back-patch to 9.2, but no further, because it seems too dangerous to change
IndexStmt or DefineIndex's API in released branches. The bug exists back
to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given
the lack of prior complaints we'll just let it go unfixed before 9.2.
14 years ago
|
|
|
extern Oid DefineIndex(IndexStmt *stmt,
|
|
|
|
|
Oid indexRelationId,
|
|
|
|
|
bool is_alter_table,
|
|
|
|
|
bool check_rights,
|
|
|
|
|
bool skip_build,
|
Avoid pre-determining index names during CREATE TABLE LIKE parsing.
Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE
had to pre-assign names to indexes that had comments, because it made up an
explicit CommentStmt command to apply the comment and so it had to know the
name for the index. This creates bad interactions with other indexes, as
shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't
take any other indexes into account so it could choose a conflicting name.
To fix, add a field to IndexStmt that allows it to carry a comment to be
assigned to the new index. (This isn't a user-exposed feature of CREATE
INDEX, only an internal option.) Now we don't need preassignment of index
names in any situation.
I also took the opportunity to refactor DefineIndex to accept the IndexStmt
as such, rather than passing all its fields individually in a mile-long
parameter list.
Back-patch to 9.2, but no further, because it seems too dangerous to change
IndexStmt or DefineIndex's API in released branches. The bug exists back
to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given
the lack of prior complaints we'll just let it go unfixed before 9.2.
14 years ago
|
|
|
bool quiet);
|
|
|
|
|
extern Oid ReindexIndex(RangeVar *indexRelation);
|
|
|
|
|
extern Oid ReindexTable(RangeVar *relation);
|
|
|
|
|
extern Oid ReindexDatabase(const char *databaseName,
|
|
|
|
|
bool do_system, bool do_user);
|
|
|
|
|
extern char *makeObjectName(const char *name1, const char *name2,
|
|
|
|
|
const char *label);
|
|
|
|
|
extern char *ChooseRelationName(const char *name1, const char *name2,
|
|
|
|
|
const char *label, Oid namespaceid);
|
|
|
|
|
extern bool CheckIndexCompatible(Oid oldId,
|
|
|
|
|
RangeVar *heapRelation,
|
|
|
|
|
char *accessMethodName,
|
|
|
|
|
List *attributeList,
|
|
|
|
|
List *exclusionOpNames);
|
|
|
|
|
extern Oid GetDefaultOpClass(Oid type_id, Oid am_id);
|
|
|
|
|
|
|
|
|
|
/* commands/functioncmds.c */
|
|
|
|
|
extern Oid CreateFunction(CreateFunctionStmt *stmt, const char *queryString);
|
|
|
|
|
extern void RemoveFunctionById(Oid funcOid);
|
|
|
|
|
extern void SetFunctionReturnType(Oid funcOid, Oid newRetType);
|
|
|
|
|
extern void SetFunctionArgType(Oid funcOid, int argIndex, Oid newArgType);
|
|
|
|
|
extern Oid AlterFunction(AlterFunctionStmt *stmt);
|
|
|
|
|
extern Oid CreateCast(CreateCastStmt *stmt);
|
|
|
|
|
extern void DropCastById(Oid castOid);
|
Rework order of checks in ALTER / SET SCHEMA
When attempting to move an object into the schema in which it already
was, for most objects classes we were correctly complaining about
exactly that ("object is already in schema"); but for some other object
classes, such as functions, we were instead complaining of a name
collision ("object already exists in schema"). The latter is wrong and
misleading, per complaint from Robert Haas in
CA+TgmoZ0+gNf7RDKRc3u5rHXffP=QjqPZKGxb4BsPz65k7qnHQ@mail.gmail.com
To fix, refactor the way these checks are done. As a bonus, the
resulting code is smaller and can also share some code with Rename
cases.
While at it, remove use of getObjectDescriptionOids() in error messages.
These are normally disallowed because of translatability considerations,
but this one had slipped through since 9.1. (Not sure that this is
worth backpatching, though, as it would create some untranslated
messages in back branches.)
This is loosely based on a patch by KaiGai Kohei, heavily reworked by
me.
13 years ago
|
|
|
extern void IsThereFunctionInNamespace(const char *proname, int pronargs,
|
|
|
|
|
oidvector *proargtypes, Oid nspOid);
|
|
|
|
|
extern void ExecuteDoStmt(DoStmt *stmt);
|
|
|
|
|
extern Oid get_cast_oid(Oid sourcetypeid, Oid targettypeid, bool missing_ok);
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
12 years ago
|
|
|
extern void interpret_function_parameter_list(List *parameters,
|
|
|
|
|
Oid languageOid,
|
|
|
|
|
bool is_aggregate,
|
|
|
|
|
const char *queryString,
|
|
|
|
|
oidvector **parameterTypes,
|
|
|
|
|
ArrayType **allParameterTypes,
|
|
|
|
|
ArrayType **parameterModes,
|
|
|
|
|
ArrayType **parameterNames,
|
|
|
|
|
List **parameterDefaults,
|
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
12 years ago
|
|
|
Oid *variadicArgType,
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
12 years ago
|
|
|
Oid *requiredResultType);
|
|
|
|
|
|
|
|
|
|
/* commands/operatorcmds.c */
|
|
|
|
|
extern Oid DefineOperator(List *names, List *parameters);
|
|
|
|
|
extern void RemoveOperatorById(Oid operOid);
|
|
|
|
|
|
|
|
|
|
/* commands/aggregatecmds.c */
|
|
|
|
|
extern Oid DefineAggregate(List *name, List *args, bool oldstyle,
|
Allow aggregate functions to be VARIADIC.
There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.
It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg(). However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it. So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.
In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation. That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about. Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.
initdb forced because of new aggvariadic field in Aggref parse nodes.
12 years ago
|
|
|
List *parameters, const char *queryString);
|
|
|
|
|
|
|
|
|
|
/* commands/opclasscmds.c */
|
|
|
|
|
extern Oid DefineOpClass(CreateOpClassStmt *stmt);
|
|
|
|
|
extern Oid DefineOpFamily(CreateOpFamilyStmt *stmt);
|
|
|
|
|
extern Oid AlterOpFamily(AlterOpFamilyStmt *stmt);
|
|
|
|
|
extern void RemoveOpClassById(Oid opclassOid);
|
|
|
|
|
extern void RemoveOpFamilyById(Oid opfamilyOid);
|
|
|
|
|
extern void RemoveAmOpEntryById(Oid entryOid);
|
|
|
|
|
extern void RemoveAmProcEntryById(Oid entryOid);
|
|
|
|
|
extern void IsThereOpClassInNamespace(const char *opcname, Oid opcmethod,
|
|
|
|
|
Oid opcnamespace);
|
|
|
|
|
extern void IsThereOpFamilyInNamespace(const char *opfname, Oid opfmethod,
|
|
|
|
|
Oid opfnamespace);
|
|
|
|
|
extern Oid get_am_oid(const char *amname, bool missing_ok);
|
|
|
|
|
extern Oid get_opclass_oid(Oid amID, List *opclassname, bool missing_ok);
|
|
|
|
|
extern Oid get_opfamily_oid(Oid amID, List *opfamilyname, bool missing_ok);
|
|
|
|
|
|
|
|
|
|
/* commands/tsearchcmds.c */
|
|
|
|
|
extern Oid DefineTSParser(List *names, List *parameters);
|
|
|
|
|
extern void RemoveTSParserById(Oid prsId);
|
|
|
|
|
|
|
|
|
|
extern Oid DefineTSDictionary(List *names, List *parameters);
|
|
|
|
|
extern void RemoveTSDictionaryById(Oid dictId);
|
|
|
|
|
extern Oid AlterTSDictionary(AlterTSDictionaryStmt *stmt);
|
|
|
|
|
|
|
|
|
|
extern Oid DefineTSTemplate(List *names, List *parameters);
|
|
|
|
|
extern void RemoveTSTemplateById(Oid tmplId);
|
|
|
|
|
|
|
|
|
|
extern Oid DefineTSConfiguration(List *names, List *parameters);
|
|
|
|
|
extern void RemoveTSConfigurationById(Oid cfgId);
|
|
|
|
|
extern Oid AlterTSConfiguration(AlterTSConfigurationStmt *stmt);
|
|
|
|
|
|
|
|
|
|
extern text *serialize_deflist(List *deflist);
|
|
|
|
|
extern List *deserialize_deflist(Datum txt);
|
|
|
|
|
|
|
|
|
|
/* commands/foreigncmds.c */
|
|
|
|
|
extern Oid AlterForeignServerOwner(const char *name, Oid newOwnerId);
|
|
|
|
|
extern void AlterForeignServerOwner_oid(Oid, Oid newOwnerId);
|
|
|
|
|
extern Oid AlterForeignDataWrapperOwner(const char *name, Oid newOwnerId);
|
|
|
|
|
extern void AlterForeignDataWrapperOwner_oid(Oid fwdId, Oid newOwnerId);
|
|
|
|
|
extern Oid CreateForeignDataWrapper(CreateFdwStmt *stmt);
|
|
|
|
|
extern Oid AlterForeignDataWrapper(AlterFdwStmt *stmt);
|
|
|
|
|
extern void RemoveForeignDataWrapperById(Oid fdwId);
|
|
|
|
|
extern Oid CreateForeignServer(CreateForeignServerStmt *stmt);
|
|
|
|
|
extern Oid AlterForeignServer(AlterForeignServerStmt *stmt);
|
|
|
|
|
extern void RemoveForeignServerById(Oid srvId);
|
|
|
|
|
extern Oid CreateUserMapping(CreateUserMappingStmt *stmt);
|
|
|
|
|
extern Oid AlterUserMapping(AlterUserMappingStmt *stmt);
|
|
|
|
|
extern Oid RemoveUserMapping(DropUserMappingStmt *stmt);
|
|
|
|
|
extern void RemoveUserMappingById(Oid umId);
|
|
|
|
|
extern void CreateForeignTable(CreateForeignTableStmt *stmt, Oid relid);
|
|
|
|
|
extern Datum transformGenericOptions(Oid catalogId,
|
|
|
|
|
Datum oldOptions,
|
|
|
|
|
List *options,
|
|
|
|
|
Oid fdwvalidator);
|
|
|
|
|
|
|
|
|
|
/* support routines in commands/define.c */
|
|
|
|
|
|
|
|
|
|
extern char *defGetString(DefElem *def);
|
|
|
|
|
extern double defGetNumeric(DefElem *def);
|
|
|
|
|
extern bool defGetBoolean(DefElem *def);
|
|
|
|
|
extern int32 defGetInt32(DefElem *def);
|
|
|
|
|
extern int64 defGetInt64(DefElem *def);
|
|
|
|
|
extern List *defGetQualifiedName(DefElem *def);
|
|
|
|
|
extern TypeName *defGetTypeName(DefElem *def);
|
|
|
|
|
extern int defGetTypeLength(DefElem *def);
|
|
|
|
|
extern DefElem *defWithOids(bool value);
|
|
|
|
|
|
|
|
|
|
#endif /* DEFREM_H */
|
