rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/utils/adt/ruleutils.c

4913 lines
128 KiB
C
Raw Normal View History

This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/**********************************************************************
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
* ruleutils.c - Functions to convert stored expressions/querytrees
* back to source text
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
*
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
* $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.223 2006/05/28 21:13:53 tgl Exp $
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
**********************************************************************/
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
#include "postgres.h"
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
#include <unistd.h>
#include <fcntl.h>
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
#include "access/genam.h"
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
#include "catalog/dependency.h"
Partial indexes work again, courtesy of Martijn van Oosterhout. Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
2001-07-16 07:07:00 +02:00
#include "catalog/heap.h"
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
#include "catalog/index.h"
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
#include "catalog/indexing.h"
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
#include "catalog/namespace.h"
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
#include "catalog/pg_authid.h"
pg_cast table, and standards-compliant CREATE/DROP CAST commands, plus extension to create binary compatible casts. Includes dependency tracking as well. pg_proc.proimplicit is now defunct, but will be removed in a separate commit. pg_dump provides a migration path from the previous scheme to declare casts. Dumping binary compatible casts is currently impossible, though.
2002-07-19 01:11:32 +02:00
#include "catalog/pg_cast.h"
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
#include "catalog/pg_constraint.h"
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
#include "catalog/pg_depend.h"
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
#include "catalog/pg_index.h"
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
#include "catalog/pg_opclass.h"
Rule deparser didn't handle unary operators correctly.
1999-09-02 05:04:04 +02:00
#include "catalog/pg_operator.h"
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
#include "catalog/pg_trigger.h"
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
#include "executor/spi.h"
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
#include "funcapi.h"
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
#include "lib/stringinfo.h"
pg_get_indexdef() didn't do quite the right thing with identifying an index's tablespace.
2004-10-17 23:17:27 +02:00
#include "miscadmin.h"
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
#include "nodes/makefuncs.h"
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
#include "optimizer/clauses.h"
#include "optimizer/tlist.h"
Use E'' strings internally only when standard_conforming_strings = 'off'. This allows pg_dump output with standard_conforming_strings = 'on' to generate proper strings that can be loaded into other databases without the backslash doubling we typically do. I have added the dumping of the standard_conforming_strings value to pg_dump. I also added standard backslash handling for plpgsql.
2006-05-27 01:48:54 +02:00
#include "parser/gramparse.h"
Rule deparser needs to quote identifiers that are spelled the same as SQL keywords.
1999-12-06 03:37:17 +01:00
#include "parser/keywords.h"
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
#include "parser/parse_expr.h"
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
#include "parser/parse_func.h"
#include "parser/parse_oper.h"
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
#include "parser/parse_type.h"
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
#include "parser/parsetree.h"
Revise handling of dropped columns in JOIN alias lists to avoid a performance problem pointed out by phil@vodafone: to wit, we were spending O(N^2) time to check dropped-ness in an N-deep join tree, even in the case where the tree was freshly constructed and couldn't possibly mention any dropped columns. Instead of recursing in get_rte_attribute_is_dropped(), change the data structure definition: the joinaliasvars list of a JOIN RTE must have a NULL Const instead of a Var at any position that references a now-dropped column. This costs nothing during normal parse-rewrite-plan path, and instead we have a linear-time update to make when loading a stored rule that might contain now-dropped columns. While at it, move the responsibility for acquring locks on relations referenced by rules into this separate function (which I therefore chose to call AcquireRewriteLocks). This saves effort --- namely, duplicated lock grabs in parser and rewriter --- in the normal path at a cost of one extra non-locked heap_open() in the stored-rule path; seems a good tradeoff. A fringe benefit is that it is now *much* clearer that we acquire lock on relations referenced in rules before we make any rewriter decisions based on their properties. (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
2005-06-04 01:05:30 +02:00
#include "rewrite/rewriteHandler.h"
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
#include "rewrite/rewriteManip.h"
Make ALTER TABLE RENAME on a view rename the view's on-select rule too. Needed to keep pg_dump from getting confused.
2001-08-12 23:35:19 +02:00
#include "rewrite/rewriteSupport.h"
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
#include "utils/array.h"
#include "utils/fmgroids.h"
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
#include "utils/lsyscache.h"
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
#include "utils/typcache.h"
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/* ----------
* Pretty formatting constants
* ----------
*/
/* Indent counts */
pgindent run.
2003-08-04 02:43:34 +02:00
#define PRETTYINDENT_STD 8
#define PRETTYINDENT_JOIN 13
#define PRETTYINDENT_JOIN_ON (PRETTYINDENT_JOIN-PRETTYINDENT_STD)
#define PRETTYINDENT_VAR 4
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/* Pretty flags */
pgindent run.
2003-08-04 02:43:34 +02:00
#define PRETTYFLAG_PAREN 1
#define PRETTYFLAG_INDENT 2
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/* macro to test if pretty action needed */
pgindent run.
2003-08-04 02:43:34 +02:00
#define PRETTY_PAREN(context) ((context)->prettyFlags & PRETTYFLAG_PAREN)
#define PRETTY_INDENT(context) ((context)->prettyFlags & PRETTYFLAG_INDENT)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
/* ----------
* Local data types
* ----------
*/
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/* Context info needed for invoking a recursive querytree display routine */
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
typedef struct
pgindent run over code.
1999-05-25 18:15:34 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf; /* output buffer to append to */
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
List *namespaces; /* List of deparse_namespace nodes */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
int prettyFlags; /* enabling of pretty-print functions */
int indentLevel; /* current indent level for prettyprint */
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
bool varprefix; /* TRUE to print prefixes on Vars */
} deparse_context;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/*
* Each level of query context around a subtree needs a level of Var namespace.
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
* A Var having varlevelsup=N refers to the N'th item (counting from 0) in
* the current context's namespaces list.
*
* The rangetable is the list of actual RTEs from the query tree.
*
* For deparsing plan trees, we allow two special RTE entries that are not
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* part of the rtable list (partly because they don't have consecutively
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
* allocated varnos).
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
*/
typedef struct
{
List *rtable; /* List of RangeTblEntry nodes */
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
int outer_varno; /* varno for outer_rte */
RangeTblEntry *outer_rte; /* special RangeTblEntry, or NULL */
int inner_varno; /* varno for inner_rte */
RangeTblEntry *inner_rte; /* special RangeTblEntry, or NULL */
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
} deparse_namespace;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* Global data
* ----------
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
static void *plan_getrulebyoid = NULL;
Queries used by ruleutils were not schema-proof.
2002-05-29 00:16:15 +02:00
static char *query_getrulebyoid = "SELECT * FROM pg_catalog.pg_rewrite WHERE oid = $1";
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
static void *plan_getviewrule = NULL;
Queries used by ruleutils were not schema-proof.
2002-05-29 00:16:15 +02:00
static char *query_getviewrule = "SELECT * FROM pg_catalog.pg_rewrite WHERE ev_class = $1 AND rulename = $2";
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* Local functions
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
*
* Most of these functions used to use fixed-size buffers to build their
* results. Now, they take an (already initialized) StringInfo object
* as a parameter, and append their text output to its contents.
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
* ----------
*/
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
static char *deparse_expression_pretty(Node *expr, List *dpcontext,
pgindent run.
2003-08-04 02:43:34 +02:00
bool forceprefix, bool showimplicit,
int prettyFlags, int startIndent);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *pg_get_viewdef_worker(Oid viewoid, int prettyFlags);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
static void decompile_column_index_array(Datum column_index_array, Oid relId,
pgindent run.
2002-09-04 22:31:48 +02:00
StringInfo buf);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *pg_get_ruledef_worker(Oid ruleoid, int prettyFlags);
static char *pg_get_indexdef_worker(Oid indexrelid, int colno,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int prettyFlags);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *pg_get_constraintdef_worker(Oid constraintId, bool fullCommand,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int prettyFlags);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *pg_get_expr_worker(text *expr, Oid relid, char *relname,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int prettyFlags);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
static void make_ruledef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
pgindent run.
2003-08-04 02:43:34 +02:00
int prettyFlags);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
static void make_viewdef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
pgindent run.
2003-08-04 02:43:34 +02:00
int prettyFlags);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
static void get_query_def(Query *query, StringInfo buf, List *parentnamespace,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
TupleDesc resultDesc, int prettyFlags, int startIndent);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
static void get_select_query_def(Query *query, deparse_context *context,
pgindent run.
2002-09-04 22:31:48 +02:00
TupleDesc resultDesc);
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
static void get_insert_query_def(Query *query, deparse_context *context);
static void get_update_query_def(Query *query, deparse_context *context);
static void get_delete_query_def(Query *query, deparse_context *context);
Fix breakage of rules using NOTIFY actions, per bug report and patch from sergiop@sinectis.com.ar.
2001-01-03 23:01:05 +01:00
static void get_utility_query_def(Query *query, deparse_context *context);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
static void get_basic_select_query(Query *query, deparse_context *context,
pgindent run.
2002-09-04 22:31:48 +02:00
TupleDesc resultDesc);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
static void get_setop_query(Node *setOp, Query *query,
pgindent run.
2002-09-04 22:31:48 +02:00
deparse_context *context,
TupleDesc resultDesc);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
static Node *get_rule_sortgroupclause(SortClause *srt, List *tlist,
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
bool force_colno,
deparse_context *context);
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
static void get_names_for_var(Var *var, int levelsup, deparse_context *context,
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
char **schemaname, char **refname, char **attname);
static RangeTblEntry *find_rte_by_refname(const char *refname,
pgindent run.
2002-09-04 22:31:48 +02:00
deparse_context *context);
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
static const char *get_simple_binary_op_name(OpExpr *expr);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
static bool isSimpleNode(Node *node, Node *parentNode, int prettyFlags);
static void appendStringInfoSpaces(StringInfo buf, int count);
static void appendContextKeyword(deparse_context *context, const char *str,
pgindent run.
2003-08-04 02:43:34 +02:00
int indentBefore, int indentAfter, int indentPlus);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
static void get_rule_expr(Node *node, deparse_context *context,
pgindent run.
2003-08-04 02:43:34 +02:00
bool showimplicit);
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
static void get_oper_expr(OpExpr *expr, deparse_context *context);
static void get_func_expr(FuncExpr *expr, deparse_context *context,
pgindent run.
2003-08-04 02:43:34 +02:00
bool showimplicit);
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
static void get_agg_expr(Aggref *aggref, deparse_context *context);
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
static void get_const_expr(Const *constval, deparse_context *context);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
static void get_sublink_expr(SubLink *sublink, deparse_context *context);
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
static void get_from_clause(Query *query, const char *prefix,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
deparse_context *context);
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
static void get_from_clause_item(Node *jtnode, Query *query,
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
deparse_context *context);
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
static void get_from_clause_alias(Alias *alias, RangeTblEntry *rte,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
deparse_context *context);
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
static void get_from_clause_coldeflist(List *names, List *types, List *typmods,
pgindent run.
2002-09-04 22:31:48 +02:00
deparse_context *context);
Ooops, I was a little too enthusiastic about suppressing default index opclasses; they might be default for some other datatype, in which case we mustn't suppress 'em.
2001-10-05 00:00:10 +02:00
static void get_opclass_name(Oid opclass, Oid actual_datatype,
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
StringInfo buf);
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
static Node *processIndirection(Node *node, deparse_context *context);
static void printSubscripts(ArrayRef *aref, deparse_context *context);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
static char *generate_relation_name(Oid relid);
static char *generate_function_name(Oid funcid, int nargs, Oid *argtypes);
static char *generate_operator_name(Oid operid, Oid arg1, Oid arg2);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static text *string_to_text(char *str);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Update rule dumper for the brave new world of ONLY.
2000-06-10 07:17:23 +02:00
#define only_marker(rte) ((rte)->inh ? "" : "ONLY ")
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* get_ruledef - Do it all and return a text
* that could be used as a statement
* to recreate the rule
* ----------
*/
Functions on 'text' type updated to new fmgr style. 'text' is now TOAST-able.
2000-07-06 07:48:31 +02:00
Datum
pg_get_ruledef(PG_FUNCTION_ARGS)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
Oid ruleoid = PG_GETARG_OID(0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_ruledef_worker(ruleoid, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_ruledef_ext(PG_FUNCTION_ARGS)
{
Oid ruleoid = PG_GETARG_OID(0);
bool pretty = PG_GETARG_BOOL(1);
int prettyFlags;
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_ruledef_worker(ruleoid, prettyFlags)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pg_get_ruledef_worker(Oid ruleoid, int prettyFlags)
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum args[1];
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
char nulls[1];
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int spirc;
HeapTuple ruletup;
TupleDesc rulettc;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
StringInfoData buf;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Do this first so that string is alloc'd in outer context not SPI's.
*/
initStringInfo(&buf);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Connect to SPI manager
*/
if (SPI_connect() != SPI_OK_CONNECT)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_connect failed");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
* On the first call prepare the plan to lookup pg_rewrite. We read
* pg_rewrite over the SPI manager instead of using the syscache to be
* checked for read access on pg_rewrite.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
if (plan_getrulebyoid == NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Oid argtypes[1];
void *plan;
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
argtypes[0] = OIDOID;
plan = SPI_prepare(query_getrulebyoid, 1, argtypes);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (plan == NULL)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_prepare failed for \"%s\"", query_getrulebyoid);
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
plan_getrulebyoid = SPI_saveplan(plan);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Get the pg_rewrite tuple for this rule
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
args[0] = ObjectIdGetDatum(ruleoid);
nulls[0] = ' ';
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
spirc = SPI_execute_plan(plan_getrulebyoid, args, nulls, true, 1);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (spirc != SPI_OK_SELECT)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "failed to get pg_rewrite tuple for rule %u", ruleoid);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (SPI_processed != 1)
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
appendStringInfo(&buf, "-");
else
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Get the rules definition and put it into executors memory
*/
ruletup = SPI_tuptable->vals[0];
rulettc = SPI_tuptable->tupdesc;
make_ruledef(&buf, ruletup, rulettc, prettyFlags);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Disconnect from SPI manager
*/
if (SPI_finish() != SPI_OK_FINISH)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_finish failed");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return buf.data;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
/* ----------
* get_viewdef - Mainly the same thing, but we
* only return the SELECT part of a view
* ----------
*/
Functions on 'text' type updated to new fmgr style. 'text' is now TOAST-able.
2000-07-06 07:48:31 +02:00
Datum
pg_get_viewdef(PG_FUNCTION_ARGS)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
/* By OID */
Oid viewoid = PG_GETARG_OID(0);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_viewdef_worker(viewoid, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_viewdef_ext(PG_FUNCTION_ARGS)
{
/* By OID */
Oid viewoid = PG_GETARG_OID(0);
bool pretty = PG_GETARG_BOOL(1);
int prettyFlags;
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_viewdef_worker(viewoid, prettyFlags)));
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
}
Datum
pg_get_viewdef_name(PG_FUNCTION_ARGS)
{
/* By qualified name */
text *viewname = PG_GETARG_TEXT_P(0);
RangeVar *viewrel;
Oid viewoid;
Remove second argument from textToQualifiedNameList(), as it is no longer used. From Jaime Casanova.
2005-05-27 02:57:49 +02:00
viewrel = makeRangeVarFromNameList(textToQualifiedNameList(viewname));
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
viewoid = RangeVarGetRelid(viewrel, false);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_viewdef_worker(viewoid, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_viewdef_name_ext(PG_FUNCTION_ARGS)
{
/* By qualified name */
text *viewname = PG_GETARG_TEXT_P(0);
bool pretty = PG_GETARG_BOOL(1);
int prettyFlags;
RangeVar *viewrel;
Oid viewoid;
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
Remove second argument from textToQualifiedNameList(), as it is no longer used. From Jaime Casanova.
2005-05-27 02:57:49 +02:00
viewrel = makeRangeVarFromNameList(textToQualifiedNameList(viewname));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
viewoid = RangeVarGetRelid(viewrel, false);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_viewdef_worker(viewoid, prettyFlags)));
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
}
/*
* Common code for by-OID and by-name variants of pg_get_viewdef
*/
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *
pg_get_viewdef_worker(Oid viewoid, int prettyFlags)
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
{
Datum args[2];
char nulls[2];
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int spirc;
HeapTuple ruletup;
TupleDesc rulettc;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
StringInfoData buf;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Do this first so that string is alloc'd in outer context not SPI's.
*/
initStringInfo(&buf);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Connect to SPI manager
*/
if (SPI_connect() != SPI_OK_CONNECT)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_connect failed");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
* On the first call prepare the plan to lookup pg_rewrite. We read
* pg_rewrite over the SPI manager instead of using the syscache to be
* checked for read access on pg_rewrite.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
if (plan_getviewrule == NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
Oid argtypes[2];
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
void *plan;
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
argtypes[0] = OIDOID;
argtypes[1] = NAMEOID;
plan = SPI_prepare(query_getviewrule, 2, argtypes);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (plan == NULL)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_prepare failed for \"%s\"", query_getviewrule);
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
plan_getviewrule = SPI_saveplan(plan);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
* Get the pg_rewrite tuple for the view's SELECT rule
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
args[0] = ObjectIdGetDatum(viewoid);
Change naming rule for ON SELECT rules of views: they're all just _RETURN now, since there's no need to keep 'em unique anymore.
2002-04-20 01:13:54 +02:00
args[1] = PointerGetDatum(ViewSelectRuleName);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
nulls[0] = ' ';
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
nulls[1] = ' ';
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
spirc = SPI_execute_plan(plan_getviewrule, args, nulls, true, 2);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (spirc != SPI_OK_SELECT)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
elog(ERROR, "failed to get pg_rewrite tuple for view %u", viewoid);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (SPI_processed != 1)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(&buf, "Not a view");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
{
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Get the rules definition and put it into executors memory
*/
ruletup = SPI_tuptable->vals[0];
rulettc = SPI_tuptable->tupdesc;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
make_viewdef(&buf, ruletup, rulettc, prettyFlags);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Disconnect from SPI manager
*/
if (SPI_finish() != SPI_OK_FINISH)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "SPI_finish failed");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return buf.data;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
/* ----------
* get_triggerdef - Get the definition of a trigger
* ----------
*/
Datum
pg_get_triggerdef(PG_FUNCTION_ARGS)
{
Oid trigid = PG_GETARG_OID(0);
HeapTuple ht_trig;
Form_pg_trigger trigrec;
StringInfoData buf;
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
Relation tgrel;
ScanKeyData skey[1];
SysScanDesc tgscan;
int findx = 0;
pgindent run.
2003-08-04 02:43:34 +02:00
char *tgname;
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
/*
* Fetch the pg_trigger tuple by the Oid of the trigger
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgrel = heap_open(TriggerRelationId, AccessShareLock);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey[0],
ObjectIdAttributeNumber,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(trigid));
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgscan = systable_beginscan(tgrel, TriggerOidIndexId, true,
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
SnapshotNow, 1, skey);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
ht_trig = systable_getnext(tgscan);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
if (!HeapTupleIsValid(ht_trig))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "could not find tuple for trigger %u", trigid);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
trigrec = (Form_pg_trigger) GETSTRUCT(ht_trig);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Start the trigger definition. Note that the trigger's name should never
* be schema-qualified, but the trigger rel's name may be.
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
*/
initStringInfo(&buf);
tgname = NameStr(trigrec->tgname);
appendStringInfo(&buf, "CREATE %sTRIGGER %s ",
trigrec->tgisconstraint ? "CONSTRAINT " : "",
quote_identifier(tgname));
if (TRIGGER_FOR_BEFORE(trigrec->tgtype))
appendStringInfo(&buf, "BEFORE");
else
appendStringInfo(&buf, "AFTER");
if (TRIGGER_FOR_INSERT(trigrec->tgtype))
{
appendStringInfo(&buf, " INSERT");
findx++;
}
if (TRIGGER_FOR_DELETE(trigrec->tgtype))
{
if (findx > 0)
appendStringInfo(&buf, " OR DELETE");
else
appendStringInfo(&buf, " DELETE");
findx++;
}
if (TRIGGER_FOR_UPDATE(trigrec->tgtype))
{
if (findx > 0)
appendStringInfo(&buf, " OR UPDATE");
else
appendStringInfo(&buf, " UPDATE");
}
appendStringInfo(&buf, " ON %s ",
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
generate_relation_name(trigrec->tgrelid));
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
if (trigrec->tgisconstraint)
{
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
if (trigrec->tgconstrrelid != InvalidOid)
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
appendStringInfo(&buf, "FROM %s ",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
generate_relation_name(trigrec->tgconstrrelid));
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
if (!trigrec->tgdeferrable)
appendStringInfo(&buf, "NOT ");
appendStringInfo(&buf, "DEFERRABLE INITIALLY ");
if (trigrec->tginitdeferred)
appendStringInfo(&buf, "DEFERRED ");
else
appendStringInfo(&buf, "IMMEDIATE ");
}
if (TRIGGER_FOR_ROW(trigrec->tgtype))
appendStringInfo(&buf, "FOR EACH ROW ");
else
appendStringInfo(&buf, "FOR EACH STATEMENT ");
appendStringInfo(&buf, "EXECUTE PROCEDURE %s(",
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
generate_function_name(trigrec->tgfoid, 0, NULL));
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
if (trigrec->tgnargs > 0)
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
{
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
bytea *val;
bool isnull;
char *p;
int i;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
val = (bytea *)
DatumGetPointer(fastgetattr(ht_trig,
Anum_pg_trigger_tgargs,
tgrel->rd_att, &isnull));
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
if (isnull)
elog(ERROR, "tgargs is null for trigger %u", trigid);
p = (char *) VARDATA(val);
for (i = 0; i < trigrec->tgnargs; i++)
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
{
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
if (i > 0)
appendStringInfo(&buf, ", ");
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
/*
* We form the string literal according to the prevailing setting
* of standard_conforming_strings; we never use E''.
* User is responsible for making sure result is used correctly.
*/
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
appendStringInfoChar(&buf, '\'');
while (*p)
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
{
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
char ch = *p++;
if (SQL_STR_DOUBLE(ch, !standard_conforming_strings))
appendStringInfoChar(&buf, ch);
appendStringInfoChar(&buf, ch);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
}
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
appendStringInfoChar(&buf, '\'');
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
/* advance p to next string embedded in tgargs */
p++;
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
}
}
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
/* We deliberately do not put semi-colon at end */
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
appendStringInfo(&buf, ")");
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Clean up */
Fix coredump in pg_get_triggerdef, ensure function name is schema- qualified when necessary, simplify argument-printing code.
2003-05-20 22:35:10 +02:00
systable_endscan(tgscan);
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
heap_close(tgrel, AccessShareLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(buf.data));
This patch creates a function named pg_get_triggerdef that takes the oid of a trigger as its parameter. It is basically copied from the pg_dump code. Christopher Kings-Lynne
2003-03-20 19:58:02 +01:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
/* ----------
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
* get_indexdef - Get the definition of an index
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
*
* In the extended version, there is a colno argument as well as pretty bool.
* if colno == 0, we want a complete index definition.
* if colno > 0, we only want the Nth index key's variable or expression.
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
* ----------
*/
Another round of updates for new fmgr, mostly in the datetime code.
2000-06-09 03:11:16 +02:00
Datum
pg_get_indexdef(PG_FUNCTION_ARGS)
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Another round of updates for new fmgr, mostly in the datetime code.
2000-06-09 03:11:16 +02:00
Oid indexrelid = PG_GETARG_OID(0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_indexdef_worker(indexrelid, 0, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_indexdef_ext(PG_FUNCTION_ARGS)
{
Oid indexrelid = PG_GETARG_OID(0);
pgindent run.
2003-08-04 02:43:34 +02:00
int32 colno = PG_GETARG_INT32(1);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
bool pretty = PG_GETARG_BOOL(2);
int prettyFlags;
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_indexdef_worker(indexrelid, colno, prettyFlags)));
}
/* Internal version that returns a palloc'd C string */
char *
pg_get_indexdef_string(Oid indexrelid)
{
return pg_get_indexdef_worker(indexrelid, 0, 0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pg_get_indexdef_worker(Oid indexrelid, int colno, int prettyFlags)
{
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
HeapTuple ht_idx;
HeapTuple ht_idxrel;
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
HeapTuple ht_am;
pgindent run over code.
1999-05-25 18:15:34 +02:00
Form_pg_index idxrec;
Form_pg_class idxrelrec;
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
Form_pg_am amrec;
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
List *indexprs;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *indexpr_item;
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
List *context;
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Oid indrelid;
pgindent run over code.
1999-05-25 18:15:34 +02:00
int keyno;
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
Oid keycoltype;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
Datum indclassDatum;
bool isnull;
oidvector *indclass;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
StringInfoData buf;
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
char *str;
pgindent run over code.
1999-05-25 18:15:34 +02:00
char *sep;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
* Fetch the pg_index tuple by the Oid of the index
*/
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
ht_idx = SearchSysCache(INDEXRELID,
ObjectIdGetDatum(indexrelid),
0, 0, 0);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
if (!HeapTupleIsValid(ht_idx))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for index %u", indexrelid);
pgindent run over code.
1999-05-25 18:15:34 +02:00
idxrec = (Form_pg_index) GETSTRUCT(ht_idx);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
indrelid = idxrec->indrelid;
Assert(indexrelid == idxrec->indexrelid);
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
/* Must get indclass the hard way */
indclassDatum = SysCacheGetAttr(INDEXRELID, ht_idx,
Anum_pg_index_indclass, &isnull);
Assert(!isnull);
indclass = (oidvector *) DatumGetPointer(indclassDatum);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
* Fetch the pg_class tuple of the index relation
*/
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
ht_idxrel = SearchSysCache(RELOID,
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
ObjectIdGetDatum(indexrelid),
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
0, 0, 0);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
if (!HeapTupleIsValid(ht_idxrel))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for relation %u", indexrelid);
pgindent run over code.
1999-05-25 18:15:34 +02:00
idxrelrec = (Form_pg_class) GETSTRUCT(ht_idxrel);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
* Fetch the pg_am tuple of the index' access method
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
*/
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
ht_am = SearchSysCache(AMOID,
ObjectIdGetDatum(idxrelrec->relam),
0, 0, 0);
if (!HeapTupleIsValid(ht_am))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for access method %u",
idxrelrec->relam);
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
amrec = (Form_pg_am) GETSTRUCT(ht_am);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Get the index expressions, if any. (NOTE: we do not use the relcache
* versions of the expressions and predicate, because we want to display
* non-const-folded expressions.)
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
*/
if (!heap_attisnull(ht_idx, Anum_pg_index_indexprs))
{
Datum exprsDatum;
bool isnull;
char *exprsString;
exprsDatum = SysCacheGetAttr(INDEXRELID, ht_idx,
Anum_pg_index_indexprs, &isnull);
Assert(!isnull);
exprsString = DatumGetCString(DirectFunctionCall1(textout,
exprsDatum));
indexprs = (List *) stringToNode(exprsString);
pfree(exprsString);
}
else
indexprs = NIL;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
indexpr_item = list_head(indexprs);
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
context = deparse_context_for(get_rel_name(indrelid), indrelid);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Start the index definition. Note that the index's name should never be
* schema-qualified, but the indexed rel's name may be.
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
initStringInfo(&buf);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!colno)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfo(&buf, "CREATE %sINDEX %s ON %s USING %s (",
idxrec->indisunique ? "UNIQUE " : "",
quote_identifier(NameStr(idxrelrec->relname)),
generate_relation_name(indrelid),
quote_identifier(NameStr(amrec->amname)));
pgindent run over code.
1999-05-25 18:15:34 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
* Report the indexed attributes
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
*/
sep = "";
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
for (keyno = 0; keyno < idxrec->indnatts; keyno++)
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
AttrNumber attnum = idxrec->indkey.values[keyno];
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!colno)
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(&buf, sep);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
sep = ", ";
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
if (attnum != 0)
{
/* Simple index column */
char *attname;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
attname = get_relid_attribute_name(indrelid, attnum);
pgindent run.
2003-08-04 02:43:34 +02:00
if (!colno || colno == keyno + 1)
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(&buf, quote_identifier(attname));
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
keycoltype = get_atttype(indrelid, attnum);
}
else
{
/* expressional index */
Node *indexkey;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
if (indexpr_item == NULL)
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
elog(ERROR, "too few entries in indexprs list");
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
indexkey = (Node *) lfirst(indexpr_item);
indexpr_item = lnext(indexpr_item);
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
/* Deparse */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
str = deparse_expression_pretty(indexkey, context, false, false,
prettyFlags, 0);
pgindent run.
2003-08-04 02:43:34 +02:00
if (!colno || colno == keyno + 1)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
{
pgindent run.
2003-08-04 02:43:34 +02:00
/* Need parens if it's not a bare function call */
if (indexkey && IsA(indexkey, FuncExpr) &&
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
((FuncExpr *) indexkey)->funcformat == COERCE_EXPLICIT_CALL)
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(&buf, str);
pgindent run.
2003-08-04 02:43:34 +02:00
else
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(&buf, "(%s)", str);
}
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
keycoltype = exprType(indexkey);
}
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
/*
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
* Add the operator class name
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
*/
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!colno)
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
get_opclass_name(indclass->values[keyno], keycoltype,
pgindent run.
2003-08-04 02:43:34 +02:00
&buf);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!colno)
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
{
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(&buf, ')');
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
/*
* If it's a partial index, decompile and append the predicate
*/
if (!heap_attisnull(ht_idx, Anum_pg_index_indpred))
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Node *node;
Datum predDatum;
bool isnull;
char *predString;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/* Convert text string to node tree */
predDatum = SysCacheGetAttr(INDEXRELID, ht_idx,
Anum_pg_index_indpred, &isnull);
Assert(!isnull);
predString = DatumGetCString(DirectFunctionCall1(textout,
predDatum));
node = (Node *) stringToNode(predString);
pfree(predString);
/* Deparse */
str = deparse_expression_pretty(node, context, false, false,
prettyFlags, 0);
appendStringInfo(&buf, " WHERE %s", str);
pgindent run.
2003-08-04 02:43:34 +02:00
}
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
}
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Clean up */
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
ReleaseSysCache(ht_idx);
ReleaseSysCache(ht_idxrel);
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
ReleaseSysCache(ht_am);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return buf.data;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
/*
* pg_get_constraintdef
*
* Returns the definition for the constraint, ie, everything that needs to
* appear after "ALTER TABLE ... ADD CONSTRAINT <constraintname>".
*/
Datum
pg_get_constraintdef(PG_FUNCTION_ARGS)
{
pgindent run.
2002-09-04 22:31:48 +02:00
Oid constraintId = PG_GETARG_OID(0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_constraintdef_worker(constraintId,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
false, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_constraintdef_ext(PG_FUNCTION_ARGS)
{
Oid constraintId = PG_GETARG_OID(0);
bool pretty = PG_GETARG_BOOL(1);
int prettyFlags;
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_constraintdef_worker(constraintId,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
false, prettyFlags)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/* Internal version that returns a palloc'd C string */
char *
pg_get_constraintdef_string(Oid constraintId)
{
return pg_get_constraintdef_worker(constraintId, true, 0);
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *
pg_get_constraintdef_worker(Oid constraintId, bool fullCommand,
int prettyFlags)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
{
pgindent run.
2002-09-04 22:31:48 +02:00
StringInfoData buf;
Relation conDesc;
SysScanDesc conscan;
ScanKeyData skey[1];
HeapTuple tup;
Form_pg_constraint conForm;
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Fetch the pg_constraint row. There's no syscache for pg_constraint so
* we must do it the hard way.
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
conDesc = heap_open(ConstraintRelationId, AccessShareLock);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey[0],
ObjectIdAttributeNumber,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(constraintId));
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
conscan = systable_beginscan(conDesc, ConstraintOidIndexId, true,
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
SnapshotNow, 1, skey);
tup = systable_getnext(conscan);
if (!HeapTupleIsValid(tup))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "could not find tuple for constraint %u", constraintId);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
conForm = (Form_pg_constraint) GETSTRUCT(tup);
initStringInfo(&buf);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
if (fullCommand && OidIsValid(conForm->conrelid))
{
appendStringInfo(&buf, "ALTER TABLE ONLY %s ADD CONSTRAINT %s ",
generate_relation_name(conForm->conrelid),
quote_identifier(NameStr(conForm->conname)));
}
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
switch (conForm->contype)
{
case CONSTRAINT_FOREIGN:
pgindent run.
2002-09-04 22:31:48 +02:00
{
Datum val;
bool isnull;
const char *string;
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
/* Start off the constraint definition */
appendStringInfo(&buf, "FOREIGN KEY (");
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
/* Fetch and build referencing-column list */
val = heap_getattr(tup, Anum_pg_constraint_conkey,
RelationGetDescr(conDesc), &isnull);
if (isnull)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "null conkey for constraint %u",
pgindent run.
2002-09-04 22:31:48 +02:00
constraintId);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
decompile_column_index_array(val, conForm->conrelid, &buf);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
/* add foreign relation name */
appendStringInfo(&buf, ") REFERENCES %s(",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
generate_relation_name(conForm->confrelid));
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
/* Fetch and build referenced-column list */
val = heap_getattr(tup, Anum_pg_constraint_confkey,
RelationGetDescr(conDesc), &isnull);
if (isnull)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "null confkey for constraint %u",
pgindent run.
2002-09-04 22:31:48 +02:00
constraintId);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
decompile_column_index_array(val, conForm->confrelid, &buf);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
appendStringInfo(&buf, ")");
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
/* Add match type */
switch (conForm->confmatchtype)
{
case FKCONSTR_MATCH_FULL:
string = " MATCH FULL";
break;
case FKCONSTR_MATCH_PARTIAL:
string = " MATCH PARTIAL";
break;
case FKCONSTR_MATCH_UNSPECIFIED:
string = "";
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized confmatchtype: %d",
conForm->confmatchtype);
pgindent run.
2002-09-04 22:31:48 +02:00
string = ""; /* keep compiler quiet */
break;
}
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(&buf, string);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
/* Add ON UPDATE and ON DELETE clauses, if needed */
pgindent run.
2002-09-04 22:31:48 +02:00
switch (conForm->confupdtype)
{
case FKCONSTR_ACTION_NOACTION:
pgindent run.
2003-08-04 02:43:34 +02:00
string = NULL; /* suppress default */
pgindent run.
2002-09-04 22:31:48 +02:00
break;
case FKCONSTR_ACTION_RESTRICT:
string = "RESTRICT";
break;
case FKCONSTR_ACTION_CASCADE:
string = "CASCADE";
break;
case FKCONSTR_ACTION_SETNULL:
string = "SET NULL";
break;
case FKCONSTR_ACTION_SETDEFAULT:
string = "SET DEFAULT";
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized confupdtype: %d",
conForm->confupdtype);
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
string = NULL; /* keep compiler quiet */
pgindent run.
2002-09-04 22:31:48 +02:00
break;
}
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
if (string)
Don't print NO ACTION foreign key actions in dumps and psql \d.
2003-02-03 16:17:24 +01:00
appendStringInfo(&buf, " ON UPDATE %s", string);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
switch (conForm->confdeltype)
{
case FKCONSTR_ACTION_NOACTION:
pgindent run.
2003-08-04 02:43:34 +02:00
string = NULL; /* suppress default */
pgindent run.
2002-09-04 22:31:48 +02:00
break;
case FKCONSTR_ACTION_RESTRICT:
string = "RESTRICT";
break;
case FKCONSTR_ACTION_CASCADE:
string = "CASCADE";
break;
case FKCONSTR_ACTION_SETNULL:
string = "SET NULL";
break;
case FKCONSTR_ACTION_SETDEFAULT:
string = "SET DEFAULT";
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized confdeltype: %d",
conForm->confdeltype);
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
string = NULL; /* keep compiler quiet */
pgindent run.
2002-09-04 22:31:48 +02:00
break;
}
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
if (string)
Don't print NO ACTION foreign key actions in dumps and psql \d.
2003-02-03 16:17:24 +01:00
appendStringInfo(&buf, " ON DELETE %s", string);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
Fix dumping of DEFERRABLE/INITIALLY DEFERRED: > The big problem is that while pg_dump's dump_trigger() looks at > tginitdeferred and dumps accordingly, pg_get_constraintdef doesn't look > at tginitdeferred, and therefore doesn't record the requirement as part > of ALTER TABLE ADD CONSTRAINT. pg_get_constraintdef should probably be looking at condeferrable and condeferred in the pg_constraint row it's looking at. Maybe something like the attached. (Added, output only non-default values.) Stephan Szabo
2003-01-08 23:54:06 +01:00
if (conForm->condeferrable)
appendStringInfo(&buf, " DEFERRABLE");
if (conForm->condeferred)
appendStringInfo(&buf, " INITIALLY DEFERRED");
pgindent run.
2002-09-04 22:31:48 +02:00
break;
}
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
case CONSTRAINT_PRIMARY:
case CONSTRAINT_UNIQUE:
{
Datum val;
bool isnull;
/* Start off the constraint definition */
if (conForm->contype == CONSTRAINT_PRIMARY)
appendStringInfo(&buf, "PRIMARY KEY (");
else
appendStringInfo(&buf, "UNIQUE (");
/* Fetch and build target column list */
val = heap_getattr(tup, Anum_pg_constraint_conkey,
RelationGetDescr(conDesc), &isnull);
if (isnull)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "null conkey for constraint %u",
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
constraintId);
decompile_column_index_array(val, conForm->conrelid, &buf);
appendStringInfo(&buf, ")");
break;
}
case CONSTRAINT_CHECK:
{
Datum val;
bool isnull;
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
char *conbin;
char *consrc;
Node *expr;
List *context;
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
/* Fetch constraint expression in parsetree form */
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
val = heap_getattr(tup, Anum_pg_constraint_conbin,
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
RelationGetDescr(conDesc), &isnull);
if (isnull)
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
elog(ERROR, "null conbin for constraint %u",
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
constraintId);
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
conbin = DatumGetCString(DirectFunctionCall1(textout, val));
expr = stringToNode(conbin);
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
/* Set up deparsing context for Var nodes in constraint */
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
if (conForm->conrelid != InvalidOid)
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
{
/* relation constraint */
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
context = deparse_context_for(get_rel_name(conForm->conrelid),
conForm->conrelid);
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
}
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
else
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
{
/* domain constraint --- can't have Vars */
context = NIL;
}
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
consrc = deparse_expression_pretty(expr, context, false, false,
prettyFlags, 0);
Updated the pg_get_constraintdef() to use conbin. Update pg_dump to use pg_get_constraintdef() for >= 70400. Rod Taylor <rbt@rbt.ca>
2003-06-25 05:56:31 +02:00
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now emit the constraint definition. There are cases where
* the constraint expression will be fully parenthesized and
* we don't need the outer parens ... but there are other
* cases where we do need 'em. Be conservative for now.
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
*
* Note that simply checking for leading '(' and trailing ')'
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* would NOT be good enough, consider "(x > 0) AND (y > 0)".
Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness.
2003-10-04 20:22:59 +02:00
*/
appendStringInfo(&buf, "CHECK (%s)", consrc);
The brackets aren't put on the CHECK constraints properly. Before patch: test=# select pg_get_constraintdef(oid) from pg_constraint; pg_get_constraintdef ------------------------------------------------------------------------------------------------- CHECK (VALUE >= 0) CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR ((a)::text = 'dfd'::text)) PRIMARY KEY (b) FOREIGN KEY (a) REFERENCES test2(b) UNIQUE (b) (5 rows) test=# select pg_get_constraintdef(oid, true) from pg_constraint; pg_get_constraintdef ----------------------------------------------------------------------------------- CHECK VALUE >= 0 CHECK a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text = 'dfd'::text PRIMARY KEY (b) FOREIGN KEY (a) REFERENCES test2(b) UNIQUE (b) (5 rows) After patch: test=# select pg_get_constraintdef(oid) from pg_constraint; pg_get_constraintdef ------------------------------------------------------------------------------------------------- CHECK (VALUE >= 0) CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR ((a)::text = 'dfd'::text)) PRIMARY KEY (b) FOREIGN KEY (a) REFERENCES test2(b) UNIQUE (b) (5 rows) test=# select pg_get_constraintdef(oid, true) from pg_constraint; pg_get_constraintdef ----------------------------------------------------------------------------------- CHECK (VALUE >= 0) ` CHECK (a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text = 'dfd'::text) PRIMARY KEY (b) FOREIGN KEY (a) REFERENCES test2(b) UNIQUE (b) (5 rows) It's important that those brackets are there to (a) match all other constraints and (b) so that people can just copy and paste them and it will work as SQL. Christopher Kings-Lynne
2003-09-29 20:55:56 +02:00
This patch makes pg_get_constraintdef support UNIQUE, PRIMARY KEY and CHECK constraints. There are apparently no other types of constraint in pg_constraint, so now all bases are covered. Also, this patch assumes that consrc for a CHECK constraint is always bracketed so that it's not necessary to add extra brackets. Christopher Kings-Lynne
2003-02-13 06:10:39 +01:00
break;
}
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
default:
OK, some of these syntax errors should be given other codes.
2003-09-15 22:03:37 +02:00
elog(ERROR, "invalid constraint type \"%c\"", conForm->contype);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
break;
}
/* Cleanup */
systable_endscan(conscan);
heap_close(conDesc, AccessShareLock);
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return buf.data;
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
}
/*
* Convert an int16[] Datum into a comma-separated list of column names
* for the indicated relation; append the list to buf.
*/
static void
decompile_column_index_array(Datum column_index_array, Oid relId,
StringInfo buf)
{
Datum *keys;
int nKeys;
int j;
/* Extract data from array of int16 */
deconstruct_array(DatumGetArrayTypeP(column_index_array),
Modify array operations to include array's element type OID in the array header, and to compute sizing and alignment of array elements the same way normal tuple access operations do --- viz, using the tupmacs.h macros att_addlength and att_align. This makes the world safe for arrays of cstrings or intervals, and should make it much easier to write array-type-polymorphic functions; as examples see the cleanups of array_out and contrib/array_iterator. By Joe Conway and Tom Lane.
2002-08-26 19:54:02 +02:00
INT2OID, 2, true, 's',
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
&keys, NULL, &nKeys);
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
for (j = 0; j < nKeys; j++)
{
char *colName;
Rewriter and planner should use only resno, not resname, to identify target columns in INSERT and UPDATE targetlists. Don't rely on resname to be accurate in ruleutils, either. This fixes bug reported by Donald Fraser, in which renaming a column referenced in a rule did not work very well.
2003-08-12 01:04:50 +02:00
colName = get_relid_attribute_name(relId, DatumGetInt16(keys[j]));
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
if (j == 0)
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(buf, quote_identifier(colName));
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
else
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfo(buf, ", %s", quote_identifier(colName));
Modify pg_dump to dump foreign-key constraints as constraints, not as sets of triggers. Also modify psql \d command to show foreign key constraints as such and hide the triggers. pg_get_constraintdef() function added to backend to support these. From Rod Taylor, code review and some editorialization by Tom Lane.
2002-08-17 01:01:21 +02:00
}
}
Partial indexes work again, courtesy of Martijn van Oosterhout. Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
2001-07-16 07:07:00 +02:00
/* ----------
* get_expr - Decompile an expression tree
*
* Input: an expression tree in nodeToString form, and a relation OID
*
* Output: reverse-listed expression
*
* Currently, the expression can only refer to a single relation, namely
* the one specified by the second parameter. This is sufficient for
* partial indexes, column default expressions, etc.
* ----------
*/
Datum
pg_get_expr(PG_FUNCTION_ARGS)
{
pgindent run.
2003-08-04 02:43:34 +02:00
text *expr = PG_GETARG_TEXT_P(0);
Oid relid = PG_GETARG_OID(1);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
char *relname;
/* Get the name for the relation */
relname = get_rel_name(relid);
if (relname == NULL)
PG_RETURN_NULL(); /* should we raise an error? */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_expr_worker(expr, relid, relname, 0)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Datum
pg_get_expr_ext(PG_FUNCTION_ARGS)
{
pgindent run.
2003-08-04 02:43:34 +02:00
text *expr = PG_GETARG_TEXT_P(0);
Oid relid = PG_GETARG_OID(1);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
bool pretty = PG_GETARG_BOOL(2);
int prettyFlags;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
char *relname;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
prettyFlags = pretty ? PRETTYFLAG_PAREN | PRETTYFLAG_INDENT : 0;
Partial indexes work again, courtesy of Martijn van Oosterhout. Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
2001-07-16 07:07:00 +02:00
/* Get the name for the relation */
relname = get_rel_name(relid);
if (relname == NULL)
PG_RETURN_NULL(); /* should we raise an error? */
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
PG_RETURN_TEXT_P(string_to_text(pg_get_expr_worker(expr, relid, relname, prettyFlags)));
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
static char *
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pg_get_expr_worker(text *expr, Oid relid, char *relname, int prettyFlags)
{
Node *node;
List *context;
char *exprstr;
char *str;
Partial indexes work again, courtesy of Martijn van Oosterhout. Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
2001-07-16 07:07:00 +02:00
/* Convert input TEXT object to C string */
exprstr = DatumGetCString(DirectFunctionCall1(textout,
PointerGetDatum(expr)));
/* Convert expression to node tree */
node = (Node *) stringToNode(exprstr);
/* Deparse */
context = deparse_context_for(relname, relid);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
str = deparse_expression_pretty(node, context, false, false,
prettyFlags, 0);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
return str;
Partial indexes work again, courtesy of Martijn van Oosterhout. Note: I didn't force an initdb, figuring that one today was enough. However, there is a new function in pg_proc.h, and pg_dump won't be able to dump partial indexes until you add that function.
2001-07-16 07:07:00 +02:00
}
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
/* ----------
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
* get_userbyid - Get a user name by roleid and
* fallback to 'unknown (OID=n)'
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
* ----------
*/
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
Datum
pg_get_userbyid(PG_FUNCTION_ARGS)
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
Oid roleid = PG_GETARG_OID(0);
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
Name result;
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
HeapTuple roletup;
Form_pg_authid role_rec;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
* Allocate space for the result
*/
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
result = (Name) palloc(NAMEDATALEN);
New NameStr macro to convert Name to Str. No need for var.data anymore. Fewer calls to nameout. Better use of RelationGetRelationName.
1999-11-08 00:08:36 +01:00
memset(NameStr(*result), 0, NAMEDATALEN);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
* Get the pg_authid entry and print the result
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
*/
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
roletup = SearchSysCache(AUTHOID,
ObjectIdGetDatum(roleid),
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
0, 0, 0);
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
if (HeapTupleIsValid(roletup))
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
role_rec = (Form_pg_authid) GETSTRUCT(roletup);
StrNCpy(NameStr(*result), NameStr(role_rec->rolname), NAMEDATALEN);
ReleaseSysCache(roletup);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
else
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
sprintf(NameStr(*result), "unknown (OID=%u)", roleid);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
PG_RETURN_NAME(result);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
/*
* pg_get_serial_sequence
* Get the name of the sequence used by a serial column,
* formatted suitably for passing to setval, nextval or currval.
*/
Datum
pg_get_serial_sequence(PG_FUNCTION_ARGS)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
text *tablename = PG_GETARG_TEXT_P(0);
text *columnname = PG_GETARG_TEXT_P(1);
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
RangeVar *tablerv;
Oid tableOid;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
char *column;
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
AttrNumber attnum;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Oid sequenceId = InvalidOid;
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
Relation depRel;
ScanKeyData key[3];
SysScanDesc scan;
HeapTuple tup;
/* Get the OID of the table */
Remove second argument from textToQualifiedNameList(), as it is no longer used. From Jaime Casanova.
2005-05-27 02:57:49 +02:00
tablerv = makeRangeVarFromNameList(textToQualifiedNameList(tablename));
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
tableOid = RangeVarGetRelid(tablerv, false);
/* Get the number of the column */
column = DatumGetCString(DirectFunctionCall1(textout,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
PointerGetDatum(columnname)));
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
attnum = get_attnum(tableOid, column);
if (attnum == InvalidAttrNumber)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("column \"%s\" of relation \"%s\" does not exist",
column, tablerv->relname)));
/* Search the dependency table for the dependent sequence */
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
depRel = heap_open(DependRelationId, AccessShareLock);
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
ScanKeyInit(&key[0],
Anum_pg_depend_refclassid,
BTEqualStrategyNumber, F_OIDEQ,
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
ObjectIdGetDatum(RelationRelationId));
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
ScanKeyInit(&key[1],
Anum_pg_depend_refobjid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(tableOid));
ScanKeyInit(&key[2],
Anum_pg_depend_refobjsubid,
BTEqualStrategyNumber, F_INT4EQ,
Int32GetDatum(attnum));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
scan = systable_beginscan(depRel, DependReferenceIndexId, true,
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
SnapshotNow, 3, key);
while (HeapTupleIsValid(tup = systable_getnext(scan)))
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Form_pg_depend deprec = (Form_pg_depend) GETSTRUCT(tup);
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We assume any internal dependency of a relation on a column must be
* what we are looking for.
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
*/
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
if (deprec->classid == RelationRelationId &&
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
deprec->objsubid == 0 &&
deprec->deptype == DEPENDENCY_INTERNAL)
{
sequenceId = deprec->objid;
break;
}
}
systable_endscan(scan);
heap_close(depRel, AccessShareLock);
if (OidIsValid(sequenceId))
{
HeapTuple classtup;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Form_pg_class classtuple;
char *nspname;
char *result;
Add pg_get_serial_sequence() function, and cause pg_dump to use it. This eliminates the assumption that a serial column's sequence will have the same name on reload that it was given in the original database. Christopher Kings-Lynne
2004-06-25 19:20:29 +02:00
/* Get the sequence's pg_class entry */
classtup = SearchSysCache(RELOID,
ObjectIdGetDatum(sequenceId),
0, 0, 0);
if (!HeapTupleIsValid(classtup))
elog(ERROR, "cache lookup failed for relation %u", sequenceId);
classtuple = (Form_pg_class) GETSTRUCT(classtup);
/* Get the namespace */
nspname = get_namespace_name(classtuple->relnamespace);
if (!nspname)
elog(ERROR, "cache lookup failed for namespace %u",
classtuple->relnamespace);
/* And construct the result string */
result = quote_qualified_identifier(nspname,
NameStr(classtuple->relname));
ReleaseSysCache(classtup);
PG_RETURN_TEXT_P(string_to_text(result));
}
PG_RETURN_NULL();
}
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
/* ----------
* deparse_expression - General utility for deparsing expressions
*
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
* calls deparse_expression_pretty with all prettyPrinting disabled
*/
char *
deparse_expression(Node *expr, List *dpcontext,
bool forceprefix, bool showimplicit)
{
pgindent run.
2003-08-04 02:43:34 +02:00
return deparse_expression_pretty(expr, dpcontext, forceprefix,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
showimplicit, 0, 0);
}
/* ----------
* deparse_expression_pretty - General utility for deparsing expressions
*
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
* expr is the node tree to be deparsed. It must be a transformed expression
* tree (ie, not the raw output of gram.y).
*
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
* dpcontext is a list of deparse_namespace nodes representing the context
* for interpreting Vars in the node tree.
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
*
* forceprefix is TRUE to force all Vars to be prefixed with their table names.
*
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
* showimplicit is TRUE to force all implicit casts to be shown explicitly.
pgindent run.
2003-08-04 02:43:34 +02:00
*
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
* tries to pretty up the output according to prettyFlags and startIndent.
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
*
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
* The result is a palloc'd string.
* ----------
*/
Fix inconsistent static-vs-not-static declarations.
2003-08-01 20:03:57 +02:00
static char *
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
deparse_expression_pretty(Node *expr, List *dpcontext,
bool forceprefix, bool showimplicit,
int prettyFlags, int startIndent)
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
{
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
StringInfoData buf;
deparse_context context;
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
initStringInfo(&buf);
context.buf = &buf;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
context.namespaces = dpcontext;
context.varprefix = forceprefix;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context.prettyFlags = prettyFlags;
context.indentLevel = startIndent;
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(expr, &context, showimplicit);
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
return buf.data;
}
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/* ----------
* deparse_context_for - Build deparse context for a single relation
*
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
* Given the reference name (alias) and OID of a relation, build deparsing
* context for an expression referencing only that relation (as varno 1,
pgindent run.
2002-09-04 22:31:48 +02:00
* varlevelsup 0). This is sufficient for many uses of deparse_expression.
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
* ----------
*/
List *
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
deparse_context_for(const char *aliasname, Oid relid)
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
{
deparse_namespace *dpns;
RangeTblEntry *rte;
dpns = (deparse_namespace *) palloc(sizeof(deparse_namespace));
/* Build a minimal RTE for the rel */
rte = makeNode(RangeTblEntry);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
rte->rtekind = RTE_RELATION;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
rte->relid = relid;
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
rte->eref = makeAlias(aliasname, NIL);
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
rte->inh = false;
rte->inFromCl = true;
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/* Build one-element rtable */
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
dpns->rtable = list_make1(rte);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
dpns->outer_varno = dpns->inner_varno = 0;
dpns->outer_rte = dpns->inner_rte = NULL;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
/* Return a one-deep namespace stack */
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
return list_make1(dpns);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
}
/*
* deparse_context_for_plan - Build deparse context for a plan node
*
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* The plan node may contain references to one or two subplans or outer
* join plan nodes. For these, pass the varno used plus a context node
* made with deparse_context_for_subplan. (Pass 0/NULL for unused inputs.)
Further tweaks to support display of sort keys in EXPLAIN --- initial implementation didn't work for Sort nodes associated with Append plans.
2002-06-13 05:40:49 +02:00
*
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* The plan's rangetable list must also be passed. We actually prefer to use
* the rangetable to resolve simple Vars, but the subplan inputs are needed
* for Vars that reference expressions computed in subplan target lists.
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
*/
List *
deparse_context_for_plan(int outer_varno, Node *outercontext,
Further tweaks to support display of sort keys in EXPLAIN --- initial implementation didn't work for Sort nodes associated with Append plans.
2002-06-13 05:40:49 +02:00
int inner_varno, Node *innercontext,
List *rtable)
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
{
deparse_namespace *dpns;
dpns = (deparse_namespace *) palloc(sizeof(deparse_namespace));
Further tweaks to support display of sort keys in EXPLAIN --- initial implementation didn't work for Sort nodes associated with Append plans.
2002-06-13 05:40:49 +02:00
dpns->rtable = rtable;
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
dpns->outer_varno = outer_varno;
dpns->outer_rte = (RangeTblEntry *) outercontext;
dpns->inner_varno = inner_varno;
dpns->inner_rte = (RangeTblEntry *) innercontext;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/* Return a one-deep namespace stack */
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
return list_make1(dpns);
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
}
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
/*
* deparse_context_for_subplan - Build deparse context for a plan node
*
* Helper routine to build one of the inputs for deparse_context_for_plan.
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* Pass the name to be used to reference the subplan, plus the Plan node.
* (subplan really ought to be declared as "Plan *", but we use "Node *"
* to avoid having to include plannodes.h in builtins.h.)
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
*
* The returned node is actually a RangeTblEntry, but we declare it as just
* Node to discourage callers from assuming anything.
*/
Node *
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
deparse_context_for_subplan(const char *name, Node *subplan)
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
{
RangeTblEntry *rte = makeNode(RangeTblEntry);
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
/*
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* We create an RTE_SPECIAL RangeTblEntry, and store the subplan in
* its funcexpr field. RTE_SPECIAL nodes shouldn't appear in
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
* deparse contexts otherwise.
*/
rte->rtekind = RTE_SPECIAL;
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
rte->relid = InvalidOid;
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
rte->funcexpr = subplan;
rte->alias = NULL;
rte->eref = makeAlias(name, NIL);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
rte->inh = false;
rte->inFromCl = true;
return (Node *) rte;
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* make_ruledef - reconstruct the CREATE RULE command
* for a given pg_rewrite tuple
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
make_ruledef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
int prettyFlags)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
char *rulename;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
char ev_type;
Oid ev_class;
int2 ev_attr;
bool is_instead;
char *ev_qual;
char *ev_action;
List *actions = NIL;
int fno;
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
Datum dat;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
bool isnull;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Get the attribute values from the rules tuple
*/
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
fno = SPI_fnumber(rulettc, "rulename");
dat = SPI_getbinval(ruletup, rulettc, fno, &isnull);
Assert(!isnull);
rulename = NameStr(*(DatumGetName(dat)));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
fno = SPI_fnumber(rulettc, "ev_type");
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
dat = SPI_getbinval(ruletup, rulettc, fno, &isnull);
Assert(!isnull);
ev_type = DatumGetChar(dat);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
fno = SPI_fnumber(rulettc, "ev_class");
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
dat = SPI_getbinval(ruletup, rulettc, fno, &isnull);
Assert(!isnull);
ev_class = DatumGetObjectId(dat);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
fno = SPI_fnumber(rulettc, "ev_attr");
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
dat = SPI_getbinval(ruletup, rulettc, fno, &isnull);
Assert(!isnull);
ev_attr = DatumGetInt16(dat);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
fno = SPI_fnumber(rulettc, "is_instead");
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
dat = SPI_getbinval(ruletup, rulettc, fno, &isnull);
Assert(!isnull);
is_instead = DatumGetBool(dat);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
/* these could be nulls */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
fno = SPI_fnumber(rulettc, "ev_qual");
ev_qual = SPI_getvalue(ruletup, rulettc, fno);
fno = SPI_fnumber(rulettc, "ev_action");
ev_action = SPI_getvalue(ruletup, rulettc, fno);
if (ev_action != NULL)
actions = (List *) stringToNode(ev_action);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Build the rules definition text
*/
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "CREATE RULE %s AS",
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
quote_identifier(rulename));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (prettyFlags & PRETTYFLAG_INDENT)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoString(buf, "\n ON ");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
else
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoString(buf, " ON ");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* The event the rule is fired for */
switch (ev_type)
{
case '1':
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "SELECT");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case '2':
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "UPDATE");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case '3':
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "INSERT");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case '4':
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "DELETE");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("rule \"%s\" has unsupported event type %d",
pgindent run.
2003-08-04 02:43:34 +02:00
rulename, ev_type)));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* The relation the rule is fired on */
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
appendStringInfo(buf, " TO %s", generate_relation_name(ev_class));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (ev_attr > 0)
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
appendStringInfo(buf, ".%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
quote_identifier(get_relid_attribute_name(ev_class,
ev_attr)));
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* If the rule has an event qualification, add it */
if (ev_qual == NULL)
ev_qual = "";
Fixed bug in rules event qualification output. Jan
1999-05-25 10:49:33 +02:00
if (strlen(ev_qual) > 0 && strcmp(ev_qual, "<>") != 0)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Node *qual;
Query *query;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
deparse_context context;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
deparse_namespace dpns;
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (prettyFlags & PRETTYFLAG_INDENT)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoString(buf, "\n ");
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
appendStringInfo(buf, " WHERE ");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
qual = stringToNode(ev_qual);
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
/*
* We need to make a context for recognizing any Vars in the qual
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* (which can only be references to OLD and NEW). Use the rtable of
* the first query in the action list for this purpose.
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
*/
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
query = (Query *) linitial(actions);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
/*
pgindent run.
2002-09-04 22:31:48 +02:00
* If the action is INSERT...SELECT, OLD/NEW have been pushed down
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* into the SELECT, and that's what we need to look at. (Ugly kluge
* ... try to fix this when we redesign querytrees.)
Repair problem with listing rules that have a WHERE condition and have an INSERT...SELECT as the first or only action. Per bug report from Sergio Pili.
2001-11-26 01:29:15 +01:00
*/
query = getInsertSelectQuery(query, NULL);
Revise handling of dropped columns in JOIN alias lists to avoid a performance problem pointed out by phil@vodafone: to wit, we were spending O(N^2) time to check dropped-ness in an N-deep join tree, even in the case where the tree was freshly constructed and couldn't possibly mention any dropped columns. Instead of recursing in get_rte_attribute_is_dropped(), change the data structure definition: the joinaliasvars list of a JOIN RTE must have a NULL Const instead of a Var at any position that references a now-dropped column. This costs nothing during normal parse-rewrite-plan path, and instead we have a linear-time update to make when loading a stored rule that might contain now-dropped columns. While at it, move the responsibility for acquring locks on relations referenced by rules into this separate function (which I therefore chose to call AcquireRewriteLocks). This saves effort --- namely, duplicated lock grabs in parser and rewriter --- in the normal path at a cost of one extra non-locked heap_open() in the stored-rule path; seems a good tradeoff. A fringe benefit is that it is now *much* clearer that we acquire lock on relations referenced in rules before we make any rewriter decisions based on their properties. (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
2005-06-04 01:05:30 +02:00
/* Must acquire locks right away; see notes in get_query_def() */
AcquireRewriteLocks(query);
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
context.buf = buf;
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
context.namespaces = list_make1(&dpns);
context.varprefix = (list_length(query->rtable) != 1);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context.prettyFlags = prettyFlags;
context.indentLevel = PRETTYINDENT_STD;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
dpns.rtable = query->rtable;
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
dpns.outer_varno = dpns.inner_varno = 0;
dpns.outer_rte = dpns.inner_rte = NULL;
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(qual, &context, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, " DO ");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* The INSTEAD keyword (if so) */
if (is_instead)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "INSTEAD ");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Finally the rules actions */
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (list_length(actions) > 1)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *action;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Query *query;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "(");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
foreach(action, actions)
{
query = (Query *) lfirst(action);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(query, buf, NIL, NULL, prettyFlags, 0);
if (prettyFlags)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfo(buf, ";\n");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
else
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfo(buf, "; ");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, ");");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
else if (list_length(actions) == 0)
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
{
appendStringInfo(buf, "NOTHING;");
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
{
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
Query *query;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
query = (Query *) linitial(actions);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(query, buf, NIL, NULL, prettyFlags, 0);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
appendStringInfo(buf, ";");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
}
/* ----------
* make_viewdef - reconstruct the SELECT part of a
* view rewrite rule
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
make_viewdef(StringInfo buf, HeapTuple ruletup, TupleDesc rulettc,
int prettyFlags)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Query *query;
char ev_type;
Oid ev_class;
int2 ev_attr;
bool is_instead;
char *ev_qual;
char *ev_action;
List *actions = NIL;
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
Relation ev_relation;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int fno;
bool isnull;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Get the attribute values from the rules tuple
*/
fno = SPI_fnumber(rulettc, "ev_type");
ev_type = (char) SPI_getbinval(ruletup, rulettc, fno, &isnull);
fno = SPI_fnumber(rulettc, "ev_class");
ev_class = (Oid) SPI_getbinval(ruletup, rulettc, fno, &isnull);
fno = SPI_fnumber(rulettc, "ev_attr");
ev_attr = (int2) SPI_getbinval(ruletup, rulettc, fno, &isnull);
fno = SPI_fnumber(rulettc, "is_instead");
is_instead = (bool) SPI_getbinval(ruletup, rulettc, fno, &isnull);
fno = SPI_fnumber(rulettc, "ev_qual");
ev_qual = SPI_getvalue(ruletup, rulettc, fno);
fno = SPI_fnumber(rulettc, "ev_action");
ev_action = SPI_getvalue(ruletup, rulettc, fno);
if (ev_action != NULL)
actions = (List *) stringToNode(ev_action);
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (list_length(actions) != 1)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
{
appendStringInfo(buf, "Not a view");
return;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
query = (Query *) linitial(actions);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Correct unsafe use of strcmp(). See rant of same date posted to pghackers.
2000-07-07 01:03:37 +02:00
if (ev_type != '1' || ev_attr >= 0 || !is_instead ||
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
strcmp(ev_qual, "<>") != 0 || query->commandType != CMD_SELECT)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
{
appendStringInfo(buf, "Not a view");
return;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
ev_relation = heap_open(ev_class, AccessShareLock);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(query, buf, NIL, RelationGetDescr(ev_relation),
prettyFlags, 0);
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, ";");
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
heap_close(ev_relation, AccessShareLock);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
/* ----------
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
* get_query_def - Parse back one query parsetree
*
* If resultDesc is not NULL, then it is the output tuple descriptor for
* the view represented by a SELECT query.
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_query_def(Query *query, StringInfo buf, List *parentnamespace,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
TupleDesc resultDesc, int prettyFlags, int startIndent)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
deparse_context context;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
deparse_namespace dpns;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Revise handling of dropped columns in JOIN alias lists to avoid a performance problem pointed out by phil@vodafone: to wit, we were spending O(N^2) time to check dropped-ness in an N-deep join tree, even in the case where the tree was freshly constructed and couldn't possibly mention any dropped columns. Instead of recursing in get_rte_attribute_is_dropped(), change the data structure definition: the joinaliasvars list of a JOIN RTE must have a NULL Const instead of a Var at any position that references a now-dropped column. This costs nothing during normal parse-rewrite-plan path, and instead we have a linear-time update to make when loading a stored rule that might contain now-dropped columns. While at it, move the responsibility for acquring locks on relations referenced by rules into this separate function (which I therefore chose to call AcquireRewriteLocks). This saves effort --- namely, duplicated lock grabs in parser and rewriter --- in the normal path at a cost of one extra non-locked heap_open() in the stored-rule path; seems a good tradeoff. A fringe benefit is that it is now *much* clearer that we acquire lock on relations referenced in rules before we make any rewriter decisions based on their properties. (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
2005-06-04 01:05:30 +02:00
/*
* Before we begin to examine the query, acquire locks on referenced
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* relations, and fix up deleted columns in JOIN RTEs. This ensures
* consistent results. Note we assume it's OK to scribble on the passed
* querytree!
Revise handling of dropped columns in JOIN alias lists to avoid a performance problem pointed out by phil@vodafone: to wit, we were spending O(N^2) time to check dropped-ness in an N-deep join tree, even in the case where the tree was freshly constructed and couldn't possibly mention any dropped columns. Instead of recursing in get_rte_attribute_is_dropped(), change the data structure definition: the joinaliasvars list of a JOIN RTE must have a NULL Const instead of a Var at any position that references a now-dropped column. This costs nothing during normal parse-rewrite-plan path, and instead we have a linear-time update to make when loading a stored rule that might contain now-dropped columns. While at it, move the responsibility for acquring locks on relations referenced by rules into this separate function (which I therefore chose to call AcquireRewriteLocks). This saves effort --- namely, duplicated lock grabs in parser and rewriter --- in the normal path at a cost of one extra non-locked heap_open() in the stored-rule path; seems a good tradeoff. A fringe benefit is that it is now *much* clearer that we acquire lock on relations referenced in rules before we make any rewriter decisions based on their properties. (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
2005-06-04 01:05:30 +02:00
*/
AcquireRewriteLocks(query);
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
context.buf = buf;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
context.namespaces = lcons(&dpns, list_copy(parentnamespace));
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
context.varprefix = (parentnamespace != NIL ||
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
list_length(query->rtable) != 1);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context.prettyFlags = prettyFlags;
context.indentLevel = startIndent;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
dpns.rtable = query->rtable;
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
dpns.outer_varno = dpns.inner_varno = 0;
dpns.outer_rte = dpns.inner_rte = NULL;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (query->commandType)
{
pgindent run over code.
1999-05-25 18:15:34 +02:00
case CMD_SELECT:
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_select_query_def(query, &context, resultDesc);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
case CMD_UPDATE:
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_update_query_def(query, &context);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
case CMD_INSERT:
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_insert_query_def(query, &context);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
case CMD_DELETE:
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_delete_query_def(query, &context);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
case CMD_NOTHING:
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "NOTHING");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
Fix breakage of rules using NOTIFY actions, per bug report and patch from sergiop@sinectis.com.ar.
2001-01-03 23:01:05 +01:00
case CMD_UTILITY:
get_utility_query_def(query, &context);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized query command type: %d",
Rule names are now unique per-relation, rather than unique globally. DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause, similar to TRIGGER syntaxes. To allow loading of existing pg_dump files containing COMMENT ON RULE, the COMMENT code will still accept the old syntax --- but only if the target rulename is unique across the whole database.
2002-04-18 22:01:11 +02:00
query->commandType);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
/* ----------
* get_select_query_def - Parse back a SELECT parsetree
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_select_query_def(Query *query, deparse_context *context,
TupleDesc resultDesc)
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
{
StringInfo buf = context->buf;
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
bool force_colno;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
char *sep;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If the Query node has a setOperations tree, then it's the top level of
* a UNION/INTERSECT/EXCEPT query; only the ORDER BY and LIMIT fields are
* interesting in the top query itself.
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
*/
if (query->setOperations)
{
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_setop_query(query->setOperations, query, context, resultDesc);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
/* ORDER BY clauses must be simple in this case */
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
force_colno = true;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
else
{
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_basic_select_query(query, context, resultDesc);
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
force_colno = false;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
/* Add the ORDER BY clause if given */
if (query->sortClause != NIL)
{
pgindent run.
2003-08-04 02:43:34 +02:00
appendContextKeyword(context, " ORDER BY ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 1);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
sep = "";
foreach(l, query->sortClause)
{
SortClause *srt = (SortClause *) lfirst(l);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Node *sortexpr;
Oid sortcoltype;
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
TypeCacheEntry *typentry;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
sortexpr = get_rule_sortgroupclause(srt, query->targetList,
force_colno, context);
sortcoltype = exprType(sortexpr);
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
/* See whether operator is default < or > for datatype */
typentry = lookup_type_cache(sortcoltype,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
TYPECACHE_LT_OPR | TYPECACHE_GT_OPR);
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
if (srt->sortop == typentry->lt_opr)
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/* ASC is default, so emit nothing */ ;
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
else if (srt->sortop == typentry->gt_opr)
appendStringInfo(buf, " DESC");
else
appendStringInfo(buf, " USING %s",
generate_operator_name(srt->sortop,
sortcoltype,
sortcoltype));
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
sep = ", ";
}
}
Re-implement LIMIT/OFFSET as a plan node type, instead of a hack in ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a cursor declaration will behave in a reasonable fashion, whereas before it was overridden by the FETCH count.
2000-10-26 23:38:24 +02:00
/* Add the LIMIT clause if given */
if (query->limitOffset != NULL)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " OFFSET ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->limitOffset, context, false);
Re-implement LIMIT/OFFSET as a plan node type, instead of a hack in ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a cursor declaration will behave in a reasonable fashion, whereas before it was overridden by the FETCH count.
2000-10-26 23:38:24 +02:00
}
if (query->limitCount != NULL)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " LIMIT ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Allow ORDER BY, LIMIT in sub-selects. Fix most (not all) cases where the grammar did not allow redundant parentheses around sub-selects. Distinguish LIMIT ALL from LIMIT 0; make the latter behave as one would expect.
2000-11-05 01:15:54 +01:00
if (IsA(query->limitCount, Const) &&
((Const *) query->limitCount)->constisnull)
appendStringInfo(buf, "ALL");
else
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->limitCount, context, false);
Re-implement LIMIT/OFFSET as a plan node type, instead of a hack in ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a cursor declaration will behave in a reasonable fashion, whereas before it was overridden by the FETCH count.
2000-10-26 23:38:24 +02:00
}
Fix longstanding oversight in ruleutils.c: it doesn't regurgitate a FOR UPDATE clause, if one is present.
2005-05-30 03:57:27 +02:00
Improve the representation of FOR UPDATE/FOR SHARE so that we can support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
2006-04-30 20:30:40 +02:00
/* Add FOR UPDATE/SHARE clauses if present */
foreach(l, query->rowMarks)
Fix longstanding oversight in ruleutils.c: it doesn't regurgitate a FOR UPDATE clause, if one is present.
2005-05-30 03:57:27 +02:00
{
Improve the representation of FOR UPDATE/FOR SHARE so that we can support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
2006-04-30 20:30:40 +02:00
RowMarkClause *rc = (RowMarkClause *) lfirst(l);
RangeTblEntry *rte = rt_fetch(rc->rti, query->rtable);
if (rc->forUpdate)
appendContextKeyword(context, " FOR UPDATE",
Fix longstanding oversight in ruleutils.c: it doesn't regurgitate a FOR UPDATE clause, if one is present.
2005-05-30 03:57:27 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
else
Improve the representation of FOR UPDATE/FOR SHARE so that we can support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
2006-04-30 20:30:40 +02:00
appendContextKeyword(context, " FOR SHARE",
Fix longstanding oversight in ruleutils.c: it doesn't regurgitate a FOR UPDATE clause, if one is present.
2005-05-30 03:57:27 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Improve the representation of FOR UPDATE/FOR SHARE so that we can support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
2006-04-30 20:30:40 +02:00
appendStringInfo(buf, " OF %s",
quote_identifier(rte->eref->aliasname));
if (rc->noWait)
Add NOWAIT option to SELECT FOR UPDATE/SHARE. Original patch by Hans-Juergen Schoenig, revisions by Karel Zak and Tom Lane.
2005-08-01 22:31:16 +02:00
appendStringInfo(buf, " NOWAIT");
Fix longstanding oversight in ruleutils.c: it doesn't regurgitate a FOR UPDATE clause, if one is present.
2005-05-30 03:57:27 +02:00
}
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
static void
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_basic_select_query(Query *query, deparse_context *context,
TupleDesc resultDesc)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
char *sep;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
int colno;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Build up the query string - first we say SELECT
*/
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (PRETTY_INDENT(context))
{
pgindent run.
2003-08-04 02:43:34 +02:00
context->indentLevel += PRETTYINDENT_STD;
appendStringInfoChar(buf, ' ');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "SELECT");
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
/* Add the DISTINCT clause if given */
if (query->distinctClause != NIL)
{
Fix optimizer to not try to push WHERE clauses down into a sub-SELECT that has a DISTINCT ON clause, per bug report from Anthony Wood. While at it, improve the DISTINCT-ON-clause recognizer routine to not be fooled by out- of-order DISTINCT lists.
2001-07-31 19:56:31 +02:00
if (has_distinct_on_clause(query))
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
{
appendStringInfo(buf, " DISTINCT ON (");
sep = "";
foreach(l, query->distinctClause)
{
SortClause *srt = (SortClause *) lfirst(l);
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
get_rule_sortgroupclause(srt, query->targetList,
false, context);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
sep = ", ";
}
appendStringInfo(buf, ")");
}
Fix optimizer to not try to push WHERE clauses down into a sub-SELECT that has a DISTINCT ON clause, per bug report from Anthony Wood. While at it, improve the DISTINCT-ON-clause recognizer routine to not be fooled by out- of-order DISTINCT lists.
2001-07-31 19:56:31 +02:00
else
appendStringInfo(buf, " DISTINCT");
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Then we tell what to select (the targetlist) */
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
sep = " ";
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
colno = 0;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
foreach(l, query->targetList)
{
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
TargetEntry *tle = (TargetEntry *) lfirst(l);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
char *colname;
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
char *attname;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Merge Resdom nodes into TargetEntry nodes to simplify code and save a few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
2005-04-06 18:34:07 +02:00
if (tle->resjunk)
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
continue; /* ignore junk entries */
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
sep = ", ";
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
colno++;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
/*
* We special-case Var nodes rather than using get_rule_expr.
* This is needed because get_rule_expr will display a whole-row Var
* as "foo.*", which is the preferred notation in most contexts, but
* at the top level of a SELECT list it's not right (the parser will
* expand that notation into multiple columns, yielding behavior
* different from a whole-row Var). We want just "foo", instead.
*/
if (tle->expr && IsA(tle->expr, Var))
{
Var *var = (Var *) (tle->expr);
char *schemaname;
char *refname;
get_names_for_var(var, 0, context,
&schemaname, &refname, &attname);
if (refname && (context->varprefix || attname == NULL))
{
if (schemaname)
appendStringInfo(buf, "%s.",
quote_identifier(schemaname));
if (strcmp(refname, "*NEW*") == 0)
appendStringInfoString(buf, "new");
else if (strcmp(refname, "*OLD*") == 0)
appendStringInfoString(buf, "old");
else
appendStringInfoString(buf, quote_identifier(refname));
if (attname)
appendStringInfoChar(buf, '.');
}
if (attname)
appendStringInfoString(buf, quote_identifier(attname));
else
{
/*
* In the whole-row Var case, refname is what the default AS
* name would be.
*/
attname = refname;
}
}
else
{
get_rule_expr((Node *) tle->expr, context, true);
/* We'll show the AS name unless it's this: */
attname = "?column?";
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Figure out what the result column should be called. In the context
* of a view, use the view's tuple descriptor (so as to pick up the
* effects of any column RENAME that's been done on the view).
* Otherwise, just use what we can find in the TLE.
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
*/
if (resultDesc && colno <= resultDesc->natts)
pgindent run.
2002-09-04 22:31:48 +02:00
colname = NameStr(resultDesc->attrs[colno - 1]->attname);
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
else
Merge Resdom nodes into TargetEntry nodes to simplify code and save a few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
2005-04-06 18:34:07 +02:00
colname = tle->resname;
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
/* Show AS unless the column's name is correct as-is */
Rewriter and planner should use only resno, not resname, to identify target columns in INSERT and UPDATE targetlists. Don't rely on resname to be accurate in ruleutils, either. This fixes bug reported by Donald Fraser, in which renaming a column referenced in a rule did not work very well.
2003-08-12 01:04:50 +02:00
if (colname) /* resname could be NULL */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
if (attname == NULL || strcmp(attname, colname) != 0)
Rewriter and planner should use only resno, not resname, to identify target columns in INSERT and UPDATE targetlists. Don't rely on resname to be accurate in ruleutils, either. This fixes bug reported by Donald Fraser, in which renaming a column referenced in a rule did not work very well.
2003-08-12 01:04:50 +02:00
appendStringInfo(buf, " AS %s", quote_identifier(colname));
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
/* Add the FROM clause if needed */
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
get_from_clause(query, " FROM ", context);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Add the WHERE clause if given */
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
if (query->jointree->quals != NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " WHERE ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 1);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->jointree->quals, context, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
/* Add the GROUP BY clause if given */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (query->groupClause != NULL)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " GROUP BY ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 1);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
sep = "";
foreach(l, query->groupClause)
{
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
GroupClause *grp = (GroupClause *) lfirst(l);
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
get_rule_sortgroupclause(grp, query->targetList,
false, context);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
sep = ", ";
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
/* Add the HAVING clause if given */
if (query->havingQual != NULL)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " HAVING ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->havingQual, context, false);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
}
static void
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_setop_query(Node *setOp, Query *query, deparse_context *context,
TupleDesc resultDesc)
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
{
StringInfo buf = context->buf;
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
bool need_paren;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
if (IsA(setOp, RangeTblRef))
{
RangeTblRef *rtr = (RangeTblRef *) setOp;
RangeTblEntry *rte = rt_fetch(rtr->rtindex, query->rtable);
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Query *subquery = rte->subquery;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
Assert(subquery != NULL);
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
Assert(subquery->setOperations == NULL);
/* Need parens if ORDER BY, FOR UPDATE, or LIMIT; see gram.y */
need_paren = (subquery->sortClause ||
subquery->rowMarks ||
subquery->limitOffset ||
subquery->limitCount);
if (need_paren)
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(subquery, buf, context->namespaces, resultDesc,
context->prettyFlags, context->indentLevel);
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
if (need_paren)
appendStringInfoChar(buf, ')');
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
else if (IsA(setOp, SetOperationStmt))
{
SetOperationStmt *op = (SetOperationStmt *) setOp;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We force parens whenever nesting two SetOperationStmts. There are
* some cases in which parens are needed around a leaf query too, but
* those are more easily handled at the next level down (see code
* above).
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
*/
need_paren = !IsA(op->larg, RangeTblRef);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
if (need_paren)
appendStringInfoChar(buf, '(');
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_setop_query(op->larg, query, context, resultDesc);
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
if (need_paren)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_INDENT(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ' ');
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
switch (op->op)
{
case SETOP_UNION:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "UNION ",
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
break;
case SETOP_INTERSECT:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "INTERSECT ",
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
break;
case SETOP_EXCEPT:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "EXCEPT ",
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 0);
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized set op: %d",
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
(int) op->op);
}
if (op->all)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "ALL ");
if (PRETTY_INDENT(context))
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
appendContextKeyword(context, "", 0, 0, 0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
need_paren = !IsA(op->rarg, RangeTblRef);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
if (need_paren)
appendStringInfoChar(buf, '(');
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
get_setop_query(op->rarg, query, context, resultDesc);
Fix broken logic for pretty-printing parenthesis-suppression in UNION et al.
2004-07-06 06:50:21 +02:00
if (need_paren)
appendStringInfoChar(buf, ')');
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
}
else
{
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized node type: %d",
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
(int) nodeTag(setOp));
}
}
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
/*
* Display a sort/group clause.
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
*
* Also returns the expression tree, so caller need not find it again.
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
*/
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
static Node *
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
get_rule_sortgroupclause(SortClause *srt, List *tlist, bool force_colno,
deparse_context *context)
{
StringInfo buf = context->buf;
TargetEntry *tle;
Node *expr;
tle = get_sortgroupclause_tle(srt, tlist);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
expr = (Node *) tle->expr;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
/*
* Use column-number form if requested by caller or if expression is a
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* constant --- a constant is ambiguous (and will be misinterpreted by
* findTargetlistEntry()) if we dump it explicitly.
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
*/
if (force_colno || (expr && IsA(expr, Const)))
{
Merge Resdom nodes into TargetEntry nodes to simplify code and save a few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
2005-04-06 18:34:07 +02:00
Assert(!tle->resjunk);
appendStringInfo(buf, "%d", tle->resno);
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
}
else
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(expr, context, true);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
return expr;
Constant expressions that appear in ORDER BY, GROUP BY, DISTINCT ON lists should be reverse-compiled into targetlist index numbers, because that's the only interpretation the parser allows for a constant in these clauses. (Ergo, the only way they could have gotten into the list in the first place is to have come from the targetlist; so this should always work.) Per problem report from Peter E.
2001-04-15 05:14:18 +02:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* get_insert_query_def - Parse back an INSERT parsetree
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_insert_query_def(Query *query, deparse_context *context)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
RangeTblEntry *select_rte = NULL;
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
RangeTblEntry *rte;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
char *sep;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
List *strippedexprs;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If it's an INSERT ... SELECT there will be a single subquery RTE for
* the SELECT.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
foreach(l, query->rtable)
{
rte = (RangeTblEntry *) lfirst(l);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
if (rte->rtekind != RTE_SUBQUERY)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
continue;
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
if (select_rte)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "too many RTEs in INSERT");
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
select_rte = rte;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Start the query with INSERT INTO relname
*/
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
rte = rt_fetch(query->resultRelation, query->rtable);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Assert(rte->rtekind == RTE_RELATION);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (PRETTY_INDENT(context))
{
pgindent run.
2003-08-04 02:43:34 +02:00
context->indentLevel += PRETTYINDENT_STD;
appendStringInfoChar(buf, ' ');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
appendStringInfo(buf, "INSERT INTO %s (",
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
generate_relation_name(rte->relid));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
* Add the insert-column-names list, and make a list of the actual
* assignment source expressions.
*/
strippedexprs = NIL;
sep = "";
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
foreach(l, query->targetList)
{
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
TargetEntry *tle = (TargetEntry *) lfirst(l);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Merge Resdom nodes into TargetEntry nodes to simplify code and save a few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
2005-04-06 18:34:07 +02:00
if (tle->resjunk)
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
continue; /* ignore junk entries */
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
sep = ", ";
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
* Put out name of target column; look in the catalogs, not at
* tle->resname, since resname will fail to track RENAME.
*/
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(buf,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
quote_identifier(get_relid_attribute_name(rte->relid,
tle->resno)));
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Print any indirection needed (subfields or subscripts), and strip
* off the top-level nodes representing the indirection assignments.
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
strippedexprs = lappend(strippedexprs,
processIndirection((Node *) tle->expr,
context));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, ") ");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Add the VALUES or the SELECT */
Reimplementation of UNION/INTERSECT/EXCEPT. INTERSECT/EXCEPT now meet the SQL92 semantics, including support for ALL option. All three can be used in subqueries and views. DISTINCT and ORDER BY work now in views, too. This rewrite fixes many problems with cross-datatype UNIONs and INSERT/SELECT where the SELECT yields different datatypes than the INSERT needs. I did that by making UNION subqueries and SELECT in INSERT be treated like subselects-in-FROM, thereby allowing an extra level of targetlist where the datatype conversions can be inserted safely. INITDB NEEDED!
2000-10-05 21:11:39 +02:00
if (select_rte == NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "VALUES (",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 2);
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) strippedexprs, context, false);
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
appendStringInfoChar(buf, ')');
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
else
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(select_rte->subquery, buf, NIL, NULL,
context->prettyFlags, context->indentLevel);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
/* ----------
* get_update_query_def - Parse back an UPDATE parsetree
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_update_query_def(Query *query, deparse_context *context)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
StringInfo buf = context->buf;
char *sep;
RangeTblEntry *rte;
ListCell *l;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Start the query with UPDATE relname SET
*/
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
rte = rt_fetch(query->resultRelation, query->rtable);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Assert(rte->rtekind == RTE_RELATION);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (PRETTY_INDENT(context))
{
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ' ');
context->indentLevel += PRETTYINDENT_STD;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
appendStringInfo(buf, "UPDATE %s%s SET ",
Update rule dumper for the brave new world of ONLY.
2000-06-10 07:17:23 +02:00
only_marker(rte),
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
generate_relation_name(rte->relid));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Add the comma separated list of 'attname = value' */
sep = "";
foreach(l, query->targetList)
{
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
TargetEntry *tle = (TargetEntry *) lfirst(l);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Node *expr;
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
Merge Resdom nodes into TargetEntry nodes to simplify code and save a few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
2005-04-06 18:34:07 +02:00
if (tle->resjunk)
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
continue; /* ignore junk entries */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
sep = ", ";
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
/*
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
* Put out name of target column; look in the catalogs, not at
* tle->resname, since resname will fail to track RENAME.
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
*/
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
appendStringInfoString(buf,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
quote_identifier(get_relid_attribute_name(rte->relid,
tle->resno)));
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Print any indirection needed (subfields or subscripts), and strip
* off the top-level nodes representing the indirection assignments.
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
expr = processIndirection((Node *) tle->expr, context);
appendStringInfo(buf, " = ");
get_rule_expr(expr, context, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
/* Add the FROM clause if needed */
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
get_from_clause(query, " FROM ", context);
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Finally add a WHERE clause if given */
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
if (query->jointree->quals != NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " WHERE ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 1);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->jointree->quals, context, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
/* ----------
* get_delete_query_def - Parse back a DELETE parsetree
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_delete_query_def(Query *query, deparse_context *context)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
RangeTblEntry *rte;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Start the query with DELETE FROM relname
*/
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
rte = rt_fetch(query->resultRelation, query->rtable);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Assert(rte->rtekind == RTE_RELATION);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (PRETTY_INDENT(context))
{
pgindent run.
2003-08-04 02:43:34 +02:00
context->indentLevel += PRETTYINDENT_STD;
appendStringInfoChar(buf, ' ');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
Rule dumper failed to affix '*' to inheritable RTEs.
1999-10-31 19:57:42 +01:00
appendStringInfo(buf, "DELETE FROM %s%s",
Update rule dumper for the brave new world of ONLY.
2000-06-10 07:17:23 +02:00
only_marker(rte),
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
generate_relation_name(rte->relid));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Add NOWAIT option to SELECT FOR UPDATE/SHARE. Original patch by Hans-Juergen Schoenig, revisions by Karel Zak and Tom Lane.
2005-08-01 22:31:16 +02:00
/* Add the USING clause if given */
get_from_clause(query, " USING ", context);
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
/* Add a WHERE clause if given */
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
if (query->jointree->quals != NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, " WHERE ",
-PRETTYINDENT_STD, PRETTYINDENT_STD, 1);
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(query->jointree->quals, context, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
Fix breakage of rules using NOTIFY actions, per bug report and patch from sergiop@sinectis.com.ar.
2001-01-03 23:01:05 +01:00
/* ----------
* get_utility_query_def - Parse back a UTILITY parsetree
* ----------
*/
static void
get_utility_query_def(Query *query, deparse_context *context)
{
StringInfo buf = context->buf;
if (query->utilityStmt && IsA(query->utilityStmt, NotifyStmt))
{
NotifyStmt *stmt = (NotifyStmt *) query->utilityStmt;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "",
0, PRETTYINDENT_STD, 1);
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
appendStringInfo(buf, "NOTIFY %s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
quote_qualified_identifier(stmt->relation->schemaname,
stmt->relation->relname));
Fix breakage of rules using NOTIFY actions, per bug report and patch from sergiop@sinectis.com.ar.
2001-01-03 23:01:05 +01:00
}
else
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
{
/* Currently only NOTIFY utility commands can appear in rules */
elog(ERROR, "unexpected utility statement type");
}
Fix breakage of rules using NOTIFY actions, per bug report and patch from sergiop@sinectis.com.ar.
2001-01-03 23:01:05 +01:00
}
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
/*
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
* Get the RTE referenced by a (possibly nonlocal) Var.
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
*
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
* The appropriate attribute number is stored into *attno
* (do not assume that var->varattno is what to use).
*
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
* In some cases (currently only when recursing into an unnamed join)
* the Var's varlevelsup has to be interpreted with respect to a context
* above the current one; levelsup indicates the offset.
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
*/
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
static RangeTblEntry *
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
get_rte_for_var(Var *var, int levelsup, deparse_context *context,
AttrNumber *attno)
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
{
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
RangeTblEntry *rte;
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
int netlevelsup;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
deparse_namespace *dpns;
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
/* default assumption */
*attno = var->varattno;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
/* Find appropriate nesting depth */
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
netlevelsup = var->varlevelsup + levelsup;
if (netlevelsup >= list_length(context->namespaces))
elog(ERROR, "bogus varlevelsup: %d offset %d",
var->varlevelsup, levelsup);
A couple other cosmetic cleanups in new List stuff.
2004-05-26 21:30:17 +02:00
dpns = (deparse_namespace *) list_nth(context->namespaces,
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
netlevelsup);
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
/*
* Try to find the relevant RTE in this rtable. In a plan tree, it's
* likely that varno is OUTER, INNER, or 0, in which case we try to
* use varnoold instead. If the Var references an expression computed
* by a subplan, varnoold will be 0, and we fall back to looking at the
* special subplan RTEs.
*/
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (var->varno >= 1 && var->varno <= list_length(dpns->rtable))
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
rte = rt_fetch(var->varno, dpns->rtable);
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
else if (var->varnoold >= 1 && var->varnoold <= list_length(dpns->rtable))
{
rte = rt_fetch(var->varnoold, dpns->rtable);
*attno = var->varoattno;
}
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
else if (var->varno == dpns->outer_varno)
rte = dpns->outer_rte;
else if (var->varno == dpns->inner_varno)
rte = dpns->inner_rte;
else
rte = NULL;
if (rte == NULL)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "bogus varno: %d", var->varno);
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
return rte;
}
/*
* Get the schemaname, refname and attname for a (possibly nonlocal) Var.
*
* In some cases (currently only when recursing into an unnamed join)
* the Var's varlevelsup has to be interpreted with respect to a context
* above the current one; levelsup indicates the offset.
*
* schemaname is usually returned as NULL. It will be non-null only if
* use of the unqualified refname would find the wrong RTE.
*
* refname will be returned as NULL if the Var references an unnamed join.
* In this case the Var *must* be displayed without any qualification.
*
* attname will be returned as NULL if the Var represents a whole tuple
* of the relation. (Typically we'd want to display the Var as "foo.*",
* but it's convenient to return NULL to make it easier for callers to
* distinguish this case.)
*/
static void
get_names_for_var(Var *var, int levelsup, deparse_context *context,
char **schemaname, char **refname, char **attname)
{
RangeTblEntry *rte;
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
AttrNumber attnum;
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
/* Find appropriate RTE */
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
rte = get_rte_for_var(var, levelsup, context, &attnum);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
/* Emit results */
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
*schemaname = NULL; /* default assumptions */
*refname = rte->eref->aliasname;
/* Exceptions occur only if the RTE is alias-less */
if (rte->alias == NULL)
{
if (rte->rtekind == RTE_RELATION)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* It's possible that use of the bare refname would find another
* more-closely-nested RTE, or be ambiguous, in which case we need
* to specify the schemaname to avoid these errors.
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
*/
if (find_rte_by_refname(rte->eref->aliasname, context) != rte)
*schemaname =
get_namespace_name(get_rel_namespace(rte->relid));
}
else if (rte->rtekind == RTE_JOIN)
{
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
/*
* If it's an unnamed join, look at the expansion of the alias
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* variable. If it's a simple reference to one of the input vars
* then recursively find the name of that var, instead. (This
* allows correct decompiling of cases where there are identically
* named columns on both sides of the join.) When it's not a
* simple reference, we have to just return the unqualified
* variable name (this can only happen with columns that were
* merged by USING or NATURAL clauses).
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
*/
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
if (attnum > 0)
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Var *aliasvar;
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
aliasvar = (Var *) list_nth(rte->joinaliasvars, attnum - 1);
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
if (IsA(aliasvar, Var))
{
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
get_names_for_var(aliasvar,
var->varlevelsup + levelsup, context,
When displaying a Var that is a reference to a column of an unnamed join, try to display it as a reference to the underlying column instead. This is a legitimate substitution (it wouldn't be for a named join) and it fixes some cases where the display would otherwise be ambiguous. Per example from Sim Zacks.
2004-10-27 20:09:41 +02:00
schemaname, refname, attname);
return;
}
}
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
/* Unnamed join has neither schemaname nor refname */
*refname = NULL;
}
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
else if (rte->rtekind == RTE_SPECIAL)
{
/*
* This case occurs during EXPLAIN when we are looking at a
* deparse context node set up by deparse_context_for_subplan().
* If the subplan tlist provides a name, use it, but usually
* we'll end up with "?columnN?".
*/
List *tlist = ((Plan *) rte->funcexpr)->targetlist;
TargetEntry *tle = get_tle_by_resno(tlist, attnum);
if (tle && tle->resname)
{
*attname = tle->resname;
}
else
{
char buf[32];
snprintf(buf, sizeof(buf), "?column%d?", attnum);
*attname = pstrdup(buf);
}
return;
}
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
}
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
if (attnum == InvalidAttrNumber)
Make rule lister do the right thing with Vars representing whole tuples.
2001-04-18 19:04:24 +02:00
*attname = NULL;
else
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
*attname = get_rte_attribute_name(rte, attnum);
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
}
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
/*
* Get the name of a field of a Var of type RECORD.
*
* Since no actual table or view column is allowed to have type RECORD, such
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* a Var must refer to a JOIN or FUNCTION RTE or to a subquery output. We
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
* drill down to find the ultimate defining expression and attempt to infer
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* the field name from it. We ereport if we can't determine the name.
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
*
* levelsup is an extra offset to interpret the Var's varlevelsup correctly.
*
* Note: this has essentially the same logic as the parser's
* expandRecordVariable() function, but we are dealing with a different
* representation of the input context, and we only need one field name not
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
* a TupleDesc. Also, we have a special case for RTE_SPECIAL so that we can
* deal with displaying RECORD-returning functions in subplan targetlists.
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
*/
static const char *
get_name_for_var_field(Var *var, int fieldno,
int levelsup, deparse_context *context)
{
RangeTblEntry *rte;
AttrNumber attnum;
TupleDesc tupleDesc;
Node *expr;
/* Check my caller didn't mess up */
Assert(IsA(var, Var));
Assert(var->vartype == RECORDOID);
/* Find appropriate RTE */
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
rte = get_rte_for_var(var, levelsup, context, &attnum);
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
if (attnum == InvalidAttrNumber)
{
/* Var is whole-row reference to RTE, so select the right field */
return get_rte_attribute_name(rte, fieldno);
}
expr = (Node *) var; /* default if we can't drill down */
switch (rte->rtekind)
{
case RTE_RELATION:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
/*
* This case should not occur: a column of a table shouldn't have
* type RECORD. Fall through and fail (most likely) at the
* bottom.
*/
break;
case RTE_SUBQUERY:
{
/* Subselect-in-FROM: examine sub-select's output expr */
TargetEntry *ste = get_tle_by_resno(rte->subquery->targetList,
attnum);
if (ste == NULL || ste->resjunk)
elog(ERROR, "subquery %s does not have attribute %d",
rte->eref->aliasname, attnum);
expr = (Node *) ste->expr;
if (IsA(expr, Var))
{
/*
* Recurse into the sub-select to see what its Var refers
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* to. We have to build an additional level of namespace
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
* to keep in step with varlevelsup in the subselect.
*/
deparse_namespace mydpns;
const char *result;
mydpns.rtable = rte->subquery->rtable;
mydpns.outer_varno = mydpns.inner_varno = 0;
mydpns.outer_rte = mydpns.inner_rte = NULL;
context->namespaces = lcons(&mydpns, context->namespaces);
result = get_name_for_var_field((Var *) expr, fieldno,
0, context);
context->namespaces = list_delete_first(context->namespaces);
return result;
}
/* else fall through to inspect the expression */
}
break;
case RTE_JOIN:
/* Join RTE --- recursively inspect the alias variable */
Assert(attnum > 0 && attnum <= list_length(rte->joinaliasvars));
expr = (Node *) list_nth(rte->joinaliasvars, attnum - 1);
if (IsA(expr, Var))
return get_name_for_var_field((Var *) expr, fieldno,
var->varlevelsup + levelsup,
context);
/* else fall through to inspect the expression */
break;
case RTE_FUNCTION:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We couldn't get here unless a function is declared with one of
* its result columns as RECORD, which is not allowed.
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
*/
break;
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
case RTE_SPECIAL:
{
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
/*
* We are looking at a deparse context node set up by
* deparse_context_for_subplan(). The Var must refer to an
* expression computed by this subplan (or possibly one of its
* inputs), rather than any simple attribute of an RTE entry.
* Look into the subplan's target list to get the referenced
* expression, digging down as far as needed to find something
* that's not a Var, and then pass it to
* get_expr_result_type().
*/
Plan *subplan = (Plan *) rte->funcexpr;
for (;;)
{
TargetEntry *ste;
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
ste = get_tle_by_resno(subplan->targetlist,
((Var *) expr)->varattno);
if (!ste || !ste->expr)
break;
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
expr = (Node *) ste->expr;
Fix EXPLAIN so that it can drill down through multiple levels of subplan when trying to locate the referent of a RECORD variable. This fixes the 'record type has not been registered' failure reported by Stefan Kaltenbrunner about a month ago. A side effect of the way I chose to fix it is that most variable references in join conditions will now be properly labeled with the variable's source table name, instead of the not-too-helpful 'outer' or 'inner' we used to use.
2006-04-08 20:49:52 +02:00
if (!IsA(expr, Var))
break;
if (((Var *) expr)->varno == INNER)
subplan = innerPlan(subplan);
else
subplan = outerPlan(subplan);
if (!subplan)
break;
}
Repair EXPLAIN failure when trying to display a plan condition that involves selection of a field from the result of a function returning RECORD. I believe this case is new in 8.1; it's due to the addition of OUT parameters. Per example from Michael Fuhr.
2005-12-30 19:34:22 +01:00
}
break;
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
}
/*
* We now have an expression we can't expand any more, so see if
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* get_expr_result_type() can do anything with it. If not, pass to
* lookup_rowtype_tupdesc() which will probably fail, but will give an
* appropriate error message while failing.
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
*/
if (get_expr_result_type(expr, NULL, &tupleDesc) != TYPEFUNC_COMPOSITE)
tupleDesc = lookup_rowtype_tupdesc(exprType(expr), exprTypmod(expr));
/* Got the tupdesc, so we can extract the field name */
Assert(fieldno >= 1 && fieldno <= tupleDesc->natts);
return NameStr(tupleDesc->attrs[fieldno - 1]->attname);
}
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
/*
* find_rte_by_refname - look up an RTE by refname in a deparse context
*
* Returns NULL if there is no matching RTE or the refname is ambiguous.
*
* NOTE: this code is not really correct since it does not take account of
* the fact that not all the RTEs in a rangetable may be visible from the
* point where a Var reference appears. For the purposes we need, however,
* the only consequence of a false match is that we might stick a schema
* qualifier on a Var that doesn't really need it. So it seems close
* enough.
*/
static RangeTblEntry *
find_rte_by_refname(const char *refname, deparse_context *context)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
RangeTblEntry *result = NULL;
ListCell *nslist;
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
foreach(nslist, context->namespaces)
{
deparse_namespace *dpns = (deparse_namespace *) lfirst(nslist);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ListCell *rtlist;
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
foreach(rtlist, dpns->rtable)
{
RangeTblEntry *rte = (RangeTblEntry *) lfirst(rtlist);
if (strcmp(rte->eref->aliasname, refname) == 0)
{
if (result)
pgindent run.
2002-09-04 22:31:48 +02:00
return NULL; /* it's ambiguous */
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
result = rte;
}
}
if (dpns->outer_rte &&
strcmp(dpns->outer_rte->eref->aliasname, refname) == 0)
{
if (result)
return NULL; /* it's ambiguous */
result = dpns->outer_rte;
}
if (dpns->inner_rte &&
strcmp(dpns->inner_rte->eref->aliasname, refname) == 0)
{
if (result)
return NULL; /* it's ambiguous */
result = dpns->inner_rte;
}
if (result)
break;
}
return result;
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/*
* get_simple_binary_op_name
*
* helper function for isSimpleNode
* will return single char binary operator name, or NULL if it's not
*/
static const char *
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
get_simple_binary_op_name(OpExpr *expr)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
{
List *args = expr->args;
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (list_length(args) == 2)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
{
/* binary operator */
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg1 = (Node *) linitial(args);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
Node *arg2 = (Node *) lsecond(args);
const char *op;
op = generate_operator_name(expr->opno, exprType(arg1), exprType(arg2));
if (strlen(op) == 1)
pgindent run.
2003-08-04 02:43:34 +02:00
return op;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
return NULL;
}
/*
* isSimpleNode - check if given node is simple (doesn't need parenthesizing)
*
pgindent run.
2003-08-04 02:43:34 +02:00
* true : simple in the context of parent node's type
* false : not simple
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
*/
static bool
isSimpleNode(Node *node, Node *parentNode, int prettyFlags)
{
pgindent run.
2003-08-04 02:43:34 +02:00
if (!node)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
return false;
pgindent run.
2003-08-04 02:43:34 +02:00
switch (nodeTag(node))
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_Var:
case T_Const:
case T_Param:
case T_CoerceToDomainValue:
case T_SetToDefault:
/* single words: always simple */
return true;
case T_ArrayRef:
case T_ArrayExpr:
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
case T_RowExpr:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_CoalesceExpr:
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
case T_MinMaxExpr:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_NullIfExpr:
case T_Aggref:
case T_FuncExpr:
/* function-like: name(..) or name[..] */
return true;
pgindent run.
2003-08-04 02:43:34 +02:00
/* CASE keywords act as parentheses */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_CaseExpr:
return true;
case T_FieldSelect:
pgindent run.
2003-08-04 02:43:34 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
/*
* appears simple since . has top precedence, unless parent is
* T_FieldSelect itself!
*/
return (IsA(parentNode, FieldSelect) ? false : true);
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
case T_FieldStore:
/*
* treat like FieldSelect (probably doesn't matter)
*/
return (IsA(parentNode, FieldStore) ? false : true);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_CoerceToDomain:
/* maybe simple, check args */
pgindent run.
2003-08-04 02:43:34 +02:00
return isSimpleNode((Node *) ((CoerceToDomain *) node)->arg,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
node, prettyFlags);
case T_RelabelType:
pgindent run.
2003-08-04 02:43:34 +02:00
return isSimpleNode((Node *) ((RelabelType *) node)->arg,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
node, prettyFlags);
Instead of supposing (wrongly, in the general case) that the rowtype of an inheritance child table is binary-compatible with the rowtype of its parent, invent an expression node type that does the conversion correctly. Fixes the new bug exhibited by Kris Shannon as well as a lot of old bugs that would only show up when using multiple inheritance or after altering the parent table.
2004-12-12 00:26:51 +01:00
case T_ConvertRowtypeExpr:
return isSimpleNode((Node *) ((ConvertRowtypeExpr *) node)->arg,
node, prettyFlags);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case T_OpExpr:
{
pgindent run.
2003-08-04 02:43:34 +02:00
/* depends on parent node type; needs further checking */
if (prettyFlags & PRETTYFLAG_PAREN && IsA(parentNode, OpExpr))
{
const char *op;
const char *parentOp;
bool is_lopriop;
bool is_hipriop;
bool is_lopriparent;
bool is_hipriparent;
op = get_simple_binary_op_name((OpExpr *) node);
if (!op)
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
/* We know only the basic operators + - and * / % */
is_lopriop = (strchr("+-", *op) != NULL);
is_hipriop = (strchr("*/%", *op) != NULL);
if (!(is_lopriop || is_hipriop))
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
parentOp = get_simple_binary_op_name((OpExpr *) parentNode);
if (!parentOp)
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
is_lopriparent = (strchr("+-", *parentOp) != NULL);
is_hipriparent = (strchr("*/%", *parentOp) != NULL);
if (!(is_lopriparent || is_hipriparent))
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
if (is_hipriop && is_lopriparent)
return true; /* op binds tighter than parent */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
if (is_lopriop && is_hipriparent)
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Operators are same priority --- can skip parens only if
* we have (a - b) - c, not a - (b - c).
pgindent run.
2003-08-04 02:43:34 +02:00
*/
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
if (node == (Node *) linitial(((OpExpr *) parentNode)->args))
pgindent run.
2003-08-04 02:43:34 +02:00
return true;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
return false;
}
/* else do the same stuff as for T_SubLink et al. */
/* FALL THROUGH */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
case T_SubLink:
case T_NullTest:
case T_BooleanTest:
case T_DistinctExpr:
switch (nodeTag(parentNode))
{
case T_FuncExpr:
pgindent run.
2003-08-04 02:43:34 +02:00
{
/* special handling for casts */
CoercionForm type = ((FuncExpr *) parentNode)->funcformat;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
if (type == COERCE_EXPLICIT_CAST ||
type == COERCE_IMPLICIT_CAST)
return false;
return true; /* own parentheses */
}
case T_BoolExpr: /* lower precedence */
case T_ArrayRef: /* other separators */
case T_ArrayExpr: /* other separators */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
case T_RowExpr: /* other separators */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_CoalesceExpr: /* own parentheses */
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
case T_MinMaxExpr: /* own parentheses */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_NullIfExpr: /* other separators */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
case T_Aggref: /* own parentheses */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_CaseExpr: /* other separators */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
return true;
default:
return false;
}
case T_BoolExpr:
switch (nodeTag(parentNode))
{
case T_BoolExpr:
if (prettyFlags & PRETTYFLAG_PAREN)
{
BoolExprType type;
BoolExprType parentType;
pgindent run.
2003-08-04 02:43:34 +02:00
type = ((BoolExpr *) node)->boolop;
parentType = ((BoolExpr *) parentNode)->boolop;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
switch (type)
{
case NOT_EXPR:
case AND_EXPR:
if (parentType == AND_EXPR || parentType == OR_EXPR)
return true;
break;
case OR_EXPR:
if (parentType == OR_EXPR)
return true;
break;
}
}
return false;
case T_FuncExpr:
pgindent run.
2003-08-04 02:43:34 +02:00
{
/* special handling for casts */
CoercionForm type = ((FuncExpr *) parentNode)->funcformat;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
if (type == COERCE_EXPLICIT_CAST ||
type == COERCE_IMPLICIT_CAST)
return false;
return true; /* own parentheses */
}
case T_ArrayRef: /* other separators */
case T_ArrayExpr: /* other separators */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
case T_RowExpr: /* other separators */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_CoalesceExpr: /* own parentheses */
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
case T_MinMaxExpr: /* own parentheses */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_NullIfExpr: /* other separators */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
case T_Aggref: /* own parentheses */
pgindent run.
2003-08-04 02:43:34 +02:00
case T_CaseExpr: /* other separators */
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
return true;
default:
return false;
}
default:
break;
pgindent run.
2003-08-04 02:43:34 +02:00
}
/* those we don't know: in dubio complexo */
return false;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
/*
* appendStringInfoSpaces - append spaces to buffer
*/
static void
appendStringInfoSpaces(StringInfo buf, int count)
{
pgindent run.
2003-08-04 02:43:34 +02:00
while (count-- > 0)
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfoChar(buf, ' ');
}
/*
* appendContextKeyword - append a keyword to buffer
*
* If prettyPrint is enabled, perform a line break, and adjust indentation.
* Otherwise, just append the keyword.
*/
static void
appendContextKeyword(deparse_context *context, const char *str,
int indentBefore, int indentAfter, int indentPlus)
{
pgindent run.
2003-08-04 02:43:34 +02:00
if (PRETTY_INDENT(context))
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context->indentLevel += indentBefore;
appendStringInfoChar(context->buf, '\n');
appendStringInfoSpaces(context->buf,
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
Max(context->indentLevel, 0) + indentPlus);
appendStringInfoString(context->buf, str);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context->indentLevel += indentAfter;
if (context->indentLevel < 0)
context->indentLevel = 0;
pgindent run.
2003-08-04 02:43:34 +02:00
}
Tweak prettyprinting rules for saner indenting of UNION, INTERSECT, EXCEPT constructs.
2004-09-02 01:58:38 +02:00
else
appendStringInfoString(context->buf, str);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
/*
pgindent run.
2003-08-04 02:43:34 +02:00
* get_rule_expr_paren - deparse expr using get_rule_expr,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
* embracing the string with parentheses if necessary for prettyPrint.
*
* Never embrace if prettyFlags=0, because it's done in the calling node.
*
* Any node that does *not* embrace its argument node by sql syntax (with
* parentheses, non-operator keywords like CASE/WHEN/ON, or comma etc) should
* use get_rule_expr_paren instead of get_rule_expr so parentheses can be
* added.
*/
static void
pgindent run.
2003-08-04 02:43:34 +02:00
get_rule_expr_paren(Node *node, deparse_context *context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
bool showimplicit, Node *parentNode)
{
pgindent run.
2003-08-04 02:43:34 +02:00
bool need_paren;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
need_paren = PRETTY_PAREN(context) &&
!isSimpleNode(node, parentNode, context->prettyFlags);
if (need_paren)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(context->buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr(node, context, showimplicit);
if (need_paren)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(context->buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
* get_rule_expr - Parse back an expression
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
*
* Note: showimplicit determines whether we display any implicit cast that
* is present at the top of the expression tree. It is a passed argument,
* not a field of the context struct, because we change the value as we
* recurse down into the expression. In general we suppress implicit casts
* when the result type is known with certainty (eg, the arguments of an
* OR must be boolean). We display implicit casts for arguments of functions
* and operators, since this is needed to be certain that the same function
* or operator will be chosen when the expression is re-parsed.
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(Node *node, deparse_context *context,
bool showimplicit)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (node == NULL)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
return;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
* Each level of get_rule_expr must emit an indivisible term
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* (parenthesized if necessary) to ensure result is reparsed into the same
* expression tree. The only exception is that when the input is a List,
* we emit the component items comma-separated with no surrounding
* decoration; this is convenient for most callers.
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
*
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
* There might be some work left here to support additional node types.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
switch (nodeTag(node))
{
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
case T_Var:
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
Var *var = (Var *) node;
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
char *schemaname;
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
char *refname;
char *attname;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
get_names_for_var didn't do recursion for unnamed JOIN vars quite right; got it wrong when the JOIN was in an outer query level. Per example from Laurie Burrow. Also fix same issue in markTargetListOrigin. I think the latter is only a latent bug since we currently don't apply markTargetListOrigin except at the outer level ... but should do it right anyway.
2005-01-13 18:19:10 +01:00
get_names_for_var(var, 0, context,
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
&schemaname, &refname, &attname);
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
if (refname && (context->varprefix || attname == NULL))
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
{
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
if (schemaname)
appendStringInfo(buf, "%s.",
quote_identifier(schemaname));
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
if (strcmp(refname, "*NEW*") == 0)
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
appendStringInfoString(buf, "new.");
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
else if (strcmp(refname, "*OLD*") == 0)
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
appendStringInfoString(buf, "old.");
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
else
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
appendStringInfo(buf, "%s.",
Change scoping of table and join refnames to conform to SQL92: a JOIN clause with an alias is a <subquery> and therefore hides table references appearing within it, according to the spec. This is the same as the preliminary patch I posted to pgsql-patches yesterday, plus some really grotty code in ruleutils.c to reverse-list a query tree with the correct alias name depending on context. I'd rather not have done that, but unless we want to force another initdb for 7.1, there's no other way for now.
2001-02-14 22:35:07 +01:00
quote_identifier(refname));
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
}
Make rule lister do the right thing with Vars representing whole tuples.
2001-04-18 19:04:24 +02:00
if (attname)
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(buf, quote_identifier(attname));
Cause schema-qualified FROM items and schema-qualified variable references to behave according to SQL92 (or according to my current understanding of same, anyway). Per pghackers discussion way back in March 2002: thread 'Do FROM items of different schemas conflict?'
2002-08-08 03:44:31 +02:00
else
Fix display of whole-row Var appearing at the top level of a SELECT list. While we normally prefer the notation "foo.*" for a whole-row Var, that does not work at SELECT top level, because in that context the parser will assume that what is wanted is to expand the "*" into a list of separate target columns, yielding behavior different from a whole-row Var. We have to emit just "foo" instead in that context. Per report from Sokolov Yura.
2006-01-26 18:08:19 +01:00
appendStringInfoString(buf, "*");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
break;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_Const:
get_const_expr((Const *) node, context);
break;
case T_Param:
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
appendStringInfo(buf, "$%d", ((Param *) node)->paramid);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
case T_Aggref:
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
get_agg_expr((Aggref *) node, context);
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
break;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
case T_ArrayRef:
{
ArrayRef *aref = (ArrayRef *) node;
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
bool need_parens;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
/*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* Parenthesize the argument unless it's a simple Var or a
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* FieldSelect. (In particular, if it's another ArrayRef, we
* *must* parenthesize to avoid confusion.)
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
*/
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
need_parens = !IsA(aref->refexpr, Var) &&
!IsA(aref->refexpr, FieldSelect);
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
if (need_parens)
appendStringInfoChar(buf, '(');
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
get_rule_expr((Node *) aref->refexpr, context, showimplicit);
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
if (need_parens)
appendStringInfoChar(buf, ')');
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
printSubscripts(aref, context);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
* Array assignment nodes should have been handled in
* processIndirection().
*/
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
if (aref->refassgnexpr)
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
elog(ERROR, "unexpected refassgnexpr");
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
}
break;
case T_FuncExpr:
get_func_expr((FuncExpr *) node, context, showimplicit);
break;
case T_OpExpr:
get_oper_expr((OpExpr *) node, context);
break;
case T_DistinctExpr:
{
DistinctExpr *expr = (DistinctExpr *) node;
List *args = expr->args;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg1 = (Node *) linitial(args);
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
Node *arg2 = (Node *) lsecond(args);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren(arg1, context, true, node);
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
appendStringInfo(buf, " IS DISTINCT FROM ");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren(arg2, context, true, node);
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
}
break;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
case T_ScalarArrayOpExpr:
{
ScalarArrayOpExpr *expr = (ScalarArrayOpExpr *) node;
List *args = expr->args;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg1 = (Node *) linitial(args);
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
Node *arg2 = (Node *) lsecond(args);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren(arg1, context, true, node);
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
appendStringInfo(buf, " %s %s (",
generate_operator_name(expr->opno,
exprType(arg1),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
get_element_type(exprType(arg2))),
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
expr->useOr ? "ANY" : "ALL");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren(arg2, context, true, node);
appendStringInfoChar(buf, ')');
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
break;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_BoolExpr:
{
BoolExpr *expr = (BoolExpr *) node;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *first_arg = linitial(expr->args);
ListCell *arg = lnext(list_head(expr->args));
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
switch (expr->boolop)
{
case AND_EXPR:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren(first_arg, context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
false, node);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
while (arg)
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
{
appendStringInfo(buf, " AND ");
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren((Node *) lfirst(arg), context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
false, node);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
arg = lnext(arg);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
break;
case OR_EXPR:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren(first_arg, context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
false, node);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
while (arg)
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
{
appendStringInfo(buf, " OR ");
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren((Node *) lfirst(arg), context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
false, node);
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
arg = lnext(arg);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
break;
case NOT_EXPR:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "NOT ");
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren(first_arg, context,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
false, node);
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized boolop: %d",
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
(int) expr->boolop);
}
}
break;
case T_SubLink:
get_sublink_expr((SubLink *) node, context);
break;
Clean up plantree representation of SubPlan-s --- SubLink does not appear in the planned representation of a subplan at all any more, only SubPlan. This means subselect.c doesn't scribble on its input anymore, which seems like a good thing; and there are no longer three different possible interpretations of a SubLink. Simplify node naming and improve comments in primnodes.h. No change to stored rules, though.
2002-12-14 01:17:59 +01:00
case T_SubPlan:
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We cannot see an already-planned subplan in rule deparsing,
* only while EXPLAINing a query plan. For now, just punt.
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
*/
Further tweaking of parsetree & plantree representation of SubLinks. Simplify SubLink by storing just a List of operator OIDs, instead of a list of incomplete OpExprs --- that was a bizarre and bulky choice, with no redeeming social value since we have to build new OpExprs anyway when forming the plan tree.
2003-01-10 22:08:15 +01:00
if (((SubPlan *) node)->useHashTable)
appendStringInfo(buf, "(hashed subplan)");
else
appendStringInfo(buf, "(subplan)");
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
}
break;
Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist' from Param nodes, per discussion a few days ago on pghackers. Add new expression node type FieldSelect that implements the functionality where it's actually needed. Clean up some other unused fields in Func nodes as well. NOTE: initdb forced due to change in stored expression trees for rules.
2000-08-08 17:43:12 +02:00
case T_FieldSelect:
{
FieldSelect *fselect = (FieldSelect *) node;
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
Node *arg = (Node *) fselect->arg;
int fno = fselect->fieldnum;
const char *fieldname;
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
bool need_parens;
Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist' from Param nodes, per discussion a few days ago on pghackers. Add new expression node type FieldSelect that implements the functionality where it's actually needed. Clean up some other unused fields in Func nodes as well. NOTE: initdb forced due to change in stored expression trees for rules.
2000-08-08 17:43:12 +02:00
Change display of FieldSelect nodes from arg.field to field(arg), per bug report from Stefan Hadjistoytchev. There are some cases where the dot notation works, but there are more where it doesn't. Eventually ought to consider fixing the parser to allow cases like func().field, but for now this is the simplest patch.
2001-11-26 22:15:14 +01:00
/*
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
* Parenthesize the argument unless it's an ArrayRef or
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* another FieldSelect. Note in particular that it would be
* WRONG to not parenthesize a Var argument; simplicity is not
* the issue here, having the right number of names is.
Change display of FieldSelect nodes from arg.field to field(arg), per bug report from Stefan Hadjistoytchev. There are some cases where the dot notation works, but there are more where it doesn't. Eventually ought to consider fixing the parser to allow cases like func().field, but for now this is the simplest patch.
2001-11-26 22:15:14 +01:00
*/
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
need_parens = !IsA(arg, ArrayRef) &&!IsA(arg, FieldSelect);
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
if (need_parens)
appendStringInfoChar(buf, '(');
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
get_rule_expr(arg, context, true);
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
if (need_parens)
appendStringInfoChar(buf, ')');
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
/*
* If it's a Var of type RECORD, we have to find what the Var
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* refers to; otherwise we can use get_expr_result_type. If
* that fails, we try lookup_rowtype_tupdesc, which will
Teach ruleutils to drill down into RECORD-type Vars in the same way that the parser now can, so that it can reverse-list cases involving FieldSelect from a RECORD Var.
2005-05-31 05:03:59 +02:00
* probably fail too, but will ereport an acceptable message.
*/
if (IsA(arg, Var) &&
((Var *) arg)->vartype == RECORDOID)
fieldname = get_name_for_var_field((Var *) arg, fno,
0, context);
else
{
TupleDesc tupdesc;
if (get_expr_result_type(arg, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
tupdesc = lookup_rowtype_tupdesc(exprType(arg),
exprTypmod(arg));
Assert(tupdesc);
/* Got the tupdesc, so we can extract the field name */
Assert(fno >= 1 && fno <= tupdesc->natts);
fieldname = NameStr(tupdesc->attrs[fno - 1]->attname);
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, ".%s", quote_identifier(fieldname));
Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist' from Param nodes, per discussion a few days ago on pghackers. Add new expression node type FieldSelect that implements the functionality where it's actually needed. Clean up some other unused fields in Func nodes as well. NOTE: initdb forced due to change in stored expression trees for rules.
2000-08-08 17:43:12 +02:00
}
break;
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
case T_FieldStore:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We shouldn't see FieldStore here; it should have been stripped
* off by processIndirection().
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
elog(ERROR, "unexpected FieldStore");
break;
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
case T_RelabelType:
{
RelabelType *relabel = (RelabelType *) node;
pgindent run.
2003-08-04 02:43:34 +02:00
Node *arg = (Node *) relabel->arg;
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
if (relabel->relabelformat == COERCE_IMPLICIT_CAST &&
!showimplicit)
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
{
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
/* don't show the implicit cast */
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
get_rule_expr_paren(arg, context, false, node);
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
}
else
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
get_rule_expr_paren(arg, context, false, node);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(relabel->resulttype,
relabel->resulttypmod));
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
}
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
}
break;
Instead of supposing (wrongly, in the general case) that the rowtype of an inheritance child table is binary-compatible with the rowtype of its parent, invent an expression node type that does the conversion correctly. Fixes the new bug exhibited by Kris Shannon as well as a lot of old bugs that would only show up when using multiple inheritance or after altering the parent table.
2004-12-12 00:26:51 +01:00
case T_ConvertRowtypeExpr:
{
ConvertRowtypeExpr *convert = (ConvertRowtypeExpr *) node;
Node *arg = (Node *) convert->arg;
if (convert->convertformat == COERCE_IMPLICIT_CAST &&
!showimplicit)
{
/* don't show the implicit cast */
get_rule_expr_paren(arg, context, false, node);
}
else
{
if (!PRETTY_PAREN(context))
appendStringInfoChar(buf, '(');
get_rule_expr_paren(arg, context, false, node);
if (!PRETTY_PAREN(context))
appendStringInfoChar(buf, ')');
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(convert->resulttype, -1));
Instead of supposing (wrongly, in the general case) that the rowtype of an inheritance child table is binary-compatible with the rowtype of its parent, invent an expression node type that does the conversion correctly. Fixes the new bug exhibited by Kris Shannon as well as a lot of old bugs that would only show up when using multiple inheritance or after altering the parent table.
2004-12-12 00:26:51 +01:00
}
}
break;
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
case T_CaseExpr:
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
CaseExpr *caseexpr = (CaseExpr *) node;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *temp;
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "CASE",
0, PRETTYINDENT_VAR, 0);
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
if (caseexpr->arg)
{
appendStringInfoChar(buf, ' ');
get_rule_expr((Node *) caseexpr->arg, context, true);
}
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
foreach(temp, caseexpr->args)
{
CaseWhen *when = (CaseWhen *) lfirst(temp);
Teach deparsing of CASE expressions to cope with the simplified forms that simplify_boolean_equality() may leave behind. This is only relevant if the user writes something a bit silly, like CASE x=y WHEN TRUE THEN. Per example from Michael Fuhr; may or may not explain bug #2106.
2005-12-10 20:21:03 +01:00
Node *w = (Node *) when->expr;
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_INDENT(context))
appendStringInfoChar(buf, ' ');
appendContextKeyword(context, "WHEN ",
0, 0, 0);
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
if (caseexpr->arg)
{
Teach deparsing of CASE expressions to cope with the simplified forms that simplify_boolean_equality() may leave behind. This is only relevant if the user writes something a bit silly, like CASE x=y WHEN TRUE THEN. Per example from Michael Fuhr; may or may not explain bug #2106.
2005-12-10 20:21:03 +01:00
/*
* The parser should have produced WHEN clauses of
* the form "CaseTestExpr = RHS"; we want to show
* just the RHS. If the user wrote something silly
* like "CASE boolexpr WHEN TRUE THEN ...", then
* the optimizer's simplify_boolean_equality() may
* have reduced this to just "CaseTestExpr" or
* "NOT CaseTestExpr", for which we have to show
* "TRUE" or "FALSE".
*/
if (IsA(w, OpExpr))
{
Node *rhs;
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
Teach deparsing of CASE expressions to cope with the simplified forms that simplify_boolean_equality() may leave behind. This is only relevant if the user writes something a bit silly, like CASE x=y WHEN TRUE THEN. Per example from Michael Fuhr; may or may not explain bug #2106.
2005-12-10 20:21:03 +01:00
Assert(IsA(linitial(((OpExpr *) w)->args),
CaseTestExpr));
rhs = (Node *) lsecond(((OpExpr *) w)->args);
get_rule_expr(rhs, context, false);
}
else if (IsA(w, CaseTestExpr))
appendStringInfo(buf, "TRUE");
else if (not_clause(w))
{
Assert(IsA(get_notclausearg((Expr *) w),
CaseTestExpr));
appendStringInfo(buf, "FALSE");
}
else
elog(ERROR, "unexpected CASE WHEN clause: %d",
(int) nodeTag(w));
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
}
else
Teach deparsing of CASE expressions to cope with the simplified forms that simplify_boolean_equality() may leave behind. This is only relevant if the user writes something a bit silly, like CASE x=y WHEN TRUE THEN. Per example from Michael Fuhr; may or may not explain bug #2106.
2005-12-10 20:21:03 +01:00
get_rule_expr(w, context, false);
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, " THEN ");
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
get_rule_expr((Node *) when->result, context, true);
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_INDENT(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ' ');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "ELSE ",
0, 0, 0);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
get_rule_expr((Node *) caseexpr->defresult, context, true);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_INDENT(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ' ');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendContextKeyword(context, "END",
-PRETTYINDENT_VAR, 0, 0);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
case T_ArrayExpr:
{
pgindent run.
2003-08-04 02:43:34 +02:00
ArrayExpr *arrayexpr = (ArrayExpr *) node;
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
appendStringInfo(buf, "ARRAY[");
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) arrayexpr->elements, context, true);
appendStringInfoChar(buf, ']');
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
}
break;
pgindent run.
2003-08-04 02:43:34 +02:00
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
case T_RowExpr:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
RowExpr *rowexpr = (RowExpr *) node;
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
TupleDesc tupdesc = NULL;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *arg;
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
int i;
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
char *sep;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If it's a named type and not RECORD, we may have to skip
* dropped columns and/or claim there are NULLs for added
* columns.
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
*/
if (rowexpr->row_typeid != RECORDOID)
{
tupdesc = lookup_rowtype_tupdesc(rowexpr->row_typeid, -1);
Assert(list_length(rowexpr->args) <= tupdesc->natts);
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* SQL99 allows "ROW" to be omitted when there is more than
* one column, but for simplicity we always print it.
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
*/
appendStringInfo(buf, "ROW(");
sep = "";
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
i = 0;
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
foreach(arg, rowexpr->args)
{
Node *e = (Node *) lfirst(arg);
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
if (tupdesc == NULL ||
!tupdesc->attrs[i]->attisdropped)
{
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
get_rule_expr(e, context, true);
sep = ", ";
}
i++;
}
if (tupdesc != NULL)
{
while (i < tupdesc->natts)
{
if (!tupdesc->attrs[i]->attisdropped)
{
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Standardize on the assumption that the arguments of a RowExpr correspond to the physical layout of the rowtype, ie, there are dummy arguments corresponding to any dropped columns in the rowtype. We formerly had a couple of places that did it this way and several others that did not. Fixes Gaetano Mendola's "cache lookup failed for type 0" bug of 5-Aug.
2004-08-17 20:47:09 +02:00
appendStringInfo(buf, "NULL");
sep = ", ";
}
i++;
}
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
}
appendStringInfo(buf, ")");
if (rowexpr->row_format == COERCE_EXPLICIT_CAST)
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(rowexpr->row_typeid, -1));
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
}
break;
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
case T_RowCompareExpr:
{
RowCompareExpr *rcexpr = (RowCompareExpr *) node;
ListCell *arg;
char *sep;
/*
* SQL99 allows "ROW" to be omitted when there is more than
* one column, but for simplicity we always print it.
*/
appendStringInfo(buf, "(ROW(");
sep = "";
foreach(arg, rcexpr->largs)
{
Node *e = (Node *) lfirst(arg);
appendStringInfoString(buf, sep);
get_rule_expr(e, context, true);
sep = ", ";
}
/*
* We assume that the name of the first-column operator
* will do for all the rest too. This is definitely
* open to failure, eg if some but not all operators
* were renamed since the construct was parsed, but there
* seems no way to be perfect.
*/
appendStringInfo(buf, ") %s ROW(",
generate_operator_name(linitial_oid(rcexpr->opnos),
exprType(linitial(rcexpr->largs)),
exprType(linitial(rcexpr->rargs))));
sep = "";
foreach(arg, rcexpr->rargs)
{
Node *e = (Node *) lfirst(arg);
appendStringInfoString(buf, sep);
get_rule_expr(e, context, true);
sep = ", ";
}
appendStringInfo(buf, "))");
}
break;
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
case T_CoalesceExpr:
{
CoalesceExpr *coalesceexpr = (CoalesceExpr *) node;
appendStringInfo(buf, "COALESCE(");
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) coalesceexpr->args, context, true);
appendStringInfoChar(buf, ')');
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
}
break;
pgindent run.
2003-08-04 02:43:34 +02:00
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
case T_MinMaxExpr:
{
MinMaxExpr *minmaxexpr = (MinMaxExpr *) node;
switch (minmaxexpr->op)
{
case IS_GREATEST:
appendStringInfo(buf, "GREATEST(");
break;
case IS_LEAST:
appendStringInfo(buf, "LEAST(");
break;
}
get_rule_expr((Node *) minmaxexpr->args, context, true);
appendStringInfoChar(buf, ')');
}
break;
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
case T_NullIfExpr:
{
NullIfExpr *nullifexpr = (NullIfExpr *) node;
appendStringInfo(buf, "NULLIF(");
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) nullifexpr->args, context, true);
appendStringInfoChar(buf, ')');
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
}
break;
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
case T_NullTest:
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
NullTest *ntest = (NullTest *) node;
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren((Node *) ntest->arg, context, true, node);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
switch (ntest->nulltesttype)
{
case IS_NULL:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS NULL");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_NOT_NULL:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS NOT NULL");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized nulltesttype: %d",
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
(int) ntest->nulltesttype);
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
}
break;
case T_BooleanTest:
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
BooleanTest *btest = (BooleanTest *) node;
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren((Node *) btest->arg, context, false, node);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
switch (btest->booltesttype)
{
case IS_TRUE:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS TRUE");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_NOT_TRUE:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS NOT TRUE");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_FALSE:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS FALSE");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_NOT_FALSE:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS NOT FALSE");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_UNKNOWN:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS UNKNOWN");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
case IS_NOT_UNKNOWN:
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " IS NOT UNKNOWN");
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized booltesttype: %d",
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
(int) btest->booltesttype);
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add IS UNKNOWN, IS NOT UNKNOWN boolean tests, fix the existing boolean tests to return the correct results per SQL9x when given NULL inputs. Reimplement these tests as well as IS [NOT] NULL to have their own expression node types, instead of depending on special functions. From Joe Conway, with a little help from Tom Lane.
2001-06-20 00:39:12 +02:00
}
break;
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
case T_CoerceToDomain:
Code review for domain-constraints patch. Use a new ConstraintTest node type for runtime constraint checks, instead of misusing the parse-time Constraint node for the purpose. Fix some damage introduced into type coercion logic; in particular ensure that a coerced expression tree will read out the correct result type when inspected (patch had broken some RelabelType cases). Enforce domain NOT NULL constraints against columns that are omitted from an INSERT.
2002-09-01 00:10:48 +02:00
{
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
CoerceToDomain *ctest = (CoerceToDomain *) node;
pgindent run.
2003-08-04 02:43:34 +02:00
Node *arg = (Node *) ctest->arg;
Code review for domain-constraints patch. Use a new ConstraintTest node type for runtime constraint checks, instead of misusing the parse-time Constraint node for the purpose. Fix some damage introduced into type coercion logic; in particular ensure that a coerced expression tree will read out the correct result type when inspected (patch had broken some RelabelType cases). Enforce domain NOT NULL constraints against columns that are omitted from an INSERT.
2002-09-01 00:10:48 +02:00
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
if (ctest->coercionformat == COERCE_IMPLICIT_CAST &&
!showimplicit)
{
/* don't show the implicit cast */
get_rule_expr(arg, context, false);
}
else
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_rule_expr_paren(arg, context, false, node);
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(ctest->resulttype,
ctest->resulttypmod));
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
}
Code review for domain-constraints patch. Use a new ConstraintTest node type for runtime constraint checks, instead of misusing the parse-time Constraint node for the purpose. Fix some damage introduced into type coercion logic; in particular ensure that a coerced expression tree will read out the correct result type when inspected (patch had broken some RelabelType cases). Enforce domain NOT NULL constraints against columns that are omitted from an INSERT.
2002-09-01 00:10:48 +02:00
}
break;
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
case T_CoerceToDomainValue:
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
appendStringInfo(buf, "VALUE");
Restructure representation of join alias variables. An explicit JOIN now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
2002-03-12 01:52:10 +01:00
break;
Code review for UPDATE tab SET col = DEFAULT patch ... whack it around so it has some chance of working in rules ...
2003-07-03 18:34:26 +02:00
case T_SetToDefault:
appendStringInfo(buf, "DEFAULT");
break;
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
case T_List:
{
char *sep;
ListCell *l;
sep = "";
foreach(l, (List *) node)
{
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a warning when a variable is used as a format string for printf() and similar functions (if the variable is derived from untrusted data, it could include unexpected formatting sequences). This emits too many warnings to be enabled by default, but it does flag a few dubious constructs in the Postgres tree. This patch fixes up the obvious variants: functions that are passed a variable format string but no additional arguments. Most of these are harmless (e.g. the ruleutils stuff), but there is at least one actual bug here: if you create a trigger named "%sfoo", pg_dump will read uninitialized memory and fail to dump the trigger correctly.
2005-04-30 10:08:51 +02:00
appendStringInfoString(buf, sep);
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) lfirst(l), context, showimplicit);
sep = ", ";
}
}
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized node type: %d", (int) nodeTag(node));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
* get_oper_expr - Parse back an OpExpr node
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
*/
static void
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
get_oper_expr(OpExpr *expr, deparse_context *context)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
{
StringInfo buf = context->buf;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
Oid opno = expr->opno;
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
List *args = expr->args;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (list_length(args) == 2)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
{
/* binary operator */
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg1 = (Node *) linitial(args);
pgindent run.
2002-09-04 22:31:48 +02:00
Node *arg2 = (Node *) lsecond(args);
pgindent run.
2003-08-04 02:43:34 +02:00
get_rule_expr_paren(arg1, context, true, (Node *) expr);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
appendStringInfo(buf, " %s ",
generate_operator_name(opno,
exprType(arg1),
exprType(arg2)));
pgindent run.
2003-08-04 02:43:34 +02:00
get_rule_expr_paren(arg2, context, true, (Node *) expr);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
}
else
{
/* unary operator --- but which side? */
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg = (Node *) linitial(args);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
HeapTuple tp;
Form_pg_operator optup;
tp = SearchSysCache(OPEROID,
ObjectIdGetDatum(opno),
0, 0, 0);
if (!HeapTupleIsValid(tp))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for operator %u", opno);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
optup = (Form_pg_operator) GETSTRUCT(tp);
switch (optup->oprkind)
{
case 'l':
appendStringInfo(buf, "%s ",
generate_operator_name(opno,
InvalidOid,
exprType(arg)));
pgindent run.
2003-08-04 02:43:34 +02:00
get_rule_expr_paren(arg, context, true, (Node *) expr);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
break;
case 'r':
pgindent run.
2003-08-04 02:43:34 +02:00
get_rule_expr_paren(arg, context, true, (Node *) expr);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
appendStringInfo(buf, " %s",
generate_operator_name(opno,
exprType(arg),
InvalidOid));
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "bogus oprkind: %d", optup->oprkind);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
}
ReleaseSysCache(tp);
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
}
/*
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
* get_func_expr - Parse back a FuncExpr node
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Another pgindent run with updated typedefs.
2003-08-08 23:42:59 +02:00
get_func_expr(FuncExpr *expr, deparse_context *context,
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
bool showimplicit)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
Oid funcoid = expr->funcid;
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
Oid argtypes[FUNC_MAX_ARGS];
int nargs;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If the function call came from an implicit coercion, then just show the
* first argument --- unless caller wants to see implicit coercions.
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
*/
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (expr->funcformat == COERCE_IMPLICIT_CAST && !showimplicit)
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
get_rule_expr_paren((Node *) linitial(expr->args), context,
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
false, (Node *) expr);
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
return;
}
/*
pgindent run.
2003-08-04 02:43:34 +02:00
* If the function call came from a cast, then show the first argument
* plus an explicit cast operation.
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
*/
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (expr->funcformat == COERCE_EXPLICIT_CAST ||
expr->funcformat == COERCE_IMPLICIT_CAST)
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
Node *arg = linitial(expr->args);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
Oid rettype = expr->funcresulttype;
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
int32 coercedTypmod;
/* Get the typmod if this is a length-coercion function */
(void) exprIsLengthCoercion((Node *) expr, &coercedTypmod);
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
get_rule_expr_paren(arg, context, false, (Node *) expr);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(rettype, coercedTypmod));
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
Change rule dumper to produce reasonable output for casts that assign a specific length or precision, such as foo::char(8). Remove erroneous removal of user-written casts at the top level of a SELECT target item.
2000-02-26 22:13:18 +01:00
return;
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Normal function: display as proname(args). First we need to extract
* the argument datatypes.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
nargs = 0;
foreach(l, expr->args)
{
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (nargs >= FUNC_MAX_ARGS)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_ARGUMENTS),
errmsg("too many arguments")));
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
argtypes[nargs] = exprType((Node *) lfirst(l));
nargs++;
}
pgindent run.
2002-09-04 22:31:48 +02:00
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
appendStringInfo(buf, "%s(",
generate_function_name(funcoid, nargs, argtypes));
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
get_rule_expr((Node *) expr->args, context, true);
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
appendStringInfoChar(buf, ')');
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
* get_agg_expr - Parse back an Aggref node
*/
static void
get_agg_expr(Aggref *aggref, deparse_context *context)
{
StringInfo buf = context->buf;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
Oid argtype = exprType((Node *) aggref->target);
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
appendStringInfo(buf, "%s(%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
generate_function_name(aggref->aggfnoid, 1, &argtype),
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
aggref->aggdistinct ? "DISTINCT " : "");
if (aggref->aggstar)
appendStringInfo(buf, "*");
else
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
get_rule_expr((Node *) aggref->target, context, true);
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
appendStringInfoChar(buf, ')');
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
/* ----------
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
* get_const_expr
*
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
* Make a string representation of a Const
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
get_const_expr(Const *constval, deparse_context *context)
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid typoutput;
bool typIsVarlena;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
char *extval;
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
char *valptr;
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
bool isfloat = false;
bool needlabel;
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
Clean up handling of explicit NULL constants. Cases like SELECT null::text; SELECT int4fac(null); work as expected now. In some cases a NULL must be surrounded by parentheses: SELECT 2 + null; fails SELECT 2 + (null); OK This is a grammatical ambiguity that seems difficult to avoid. Other than that, NULLs seem to behave about like you'd expect. The internal implementation is that NULL constants are typed as UNKNOWN (like untyped string constants) until the parser can deduce the right type.
1999-12-24 07:43:34 +01:00
if (constval->constisnull)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Always label the type of a NULL constant to prevent misdecisions
* about type when reparsing.
Clean up handling of explicit NULL constants. Cases like SELECT null::text; SELECT int4fac(null); work as expected now. In some cases a NULL must be surrounded by parentheses: SELECT 2 + null; fails SELECT 2 + (null); OK This is a grammatical ambiguity that seems difficult to avoid. Other than that, NULLs seem to behave about like you'd expect. The internal implementation is that NULL constants are typed as UNKNOWN (like untyped string constants) until the parser can deduce the right type.
1999-12-24 07:43:34 +01:00
*/
Make ruleutils.c use format_type for printing typenames. Minor tweaks in quoting rules and recognition of implicit type coercions.
2002-04-28 02:49:13 +02:00
appendStringInfo(buf, "NULL::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(constval->consttype, -1));
Clean up handling of explicit NULL constants. Cases like SELECT null::text; SELECT int4fac(null); work as expected now. In some cases a NULL must be surrounded by parentheses: SELECT 2 + null; fails SELECT 2 + (null); OK This is a grammatical ambiguity that seems difficult to avoid. Other than that, NULLs seem to behave about like you'd expect. The internal implementation is that NULL constants are typed as UNKNOWN (like untyped string constants) until the parser can deduce the right type.
1999-12-24 07:43:34 +01:00
return;
}
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
getTypeOutputInfo(constval->consttype,
Change CREATE TYPE to require datatype output and send functions to have only one argument. (Per recent discussion, the option to accept multiple arguments is pretty useless for user-defined types, and would be a likely source of security holes if it was used.) Simplify call sites of output/send functions to not bother passing more than one argument.
2005-05-01 20:56:19 +02:00
&typoutput, &typIsVarlena);
Make ruleutils.c use format_type for printing typenames. Minor tweaks in quoting rules and recognition of implicit type coercions.
2002-04-28 02:49:13 +02:00
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
extval = OidOutputFunctionCall(typoutput, constval->constvalue);
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
switch (constval->consttype)
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
{
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
case INT2OID:
case INT4OID:
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
case INT8OID:
case OIDOID:
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
case FLOAT4OID:
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
case FLOAT8OID:
case NUMERICOID:
pgindent run.
2002-09-04 22:31:48 +02:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* These types are printed without quotes unless they contain
* values that aren't accepted by the scanner unquoted (e.g.,
* 'NaN'). Note that strtod() and friends might accept NaN,
* so we can't use that to test.
pgindent run.
2002-09-04 22:31:48 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* In reality we only need to defend against infinity and NaN,
* so we need not get too crazy about pattern matching here.
pgindent run.
2002-09-04 22:31:48 +02:00
*/
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
if (strspn(extval, "0123456789+-eE.") == strlen(extval))
{
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
appendStringInfoString(buf, extval);
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
if (strcspn(extval, "eE.") != strlen(extval))
pgindent run.
2003-08-04 02:43:34 +02:00
isfloat = true; /* it looks like a float */
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
}
pgindent run.
2002-09-04 22:31:48 +02:00
else
appendStringInfo(buf, "'%s'", extval);
}
break;
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
case BITOID:
case VARBITOID:
appendStringInfo(buf, "B'%s'", extval);
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
break;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
case BOOLOID:
pgindent run.
2002-09-04 22:31:48 +02:00
if (strcmp(extval, "t") == 0)
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
appendStringInfo(buf, "true");
else
appendStringInfo(buf, "false");
break;
default:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
/*
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
* We form the string literal according to the prevailing setting
* of standard_conforming_strings; we never use E''.
* User is responsible for making sure result is used correctly.
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
*/
appendStringInfoChar(buf, '\'');
for (valptr = extval; *valptr; valptr++)
{
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
char ch = *valptr;
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
if (SQL_STR_DOUBLE(ch, !standard_conforming_strings))
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
appendStringInfoChar(buf, ch);
Fix up pg_dump to do string escaping fully correctly for client encoding and standard_conforming_strings; likewise for the other client programs that need it. As per previous discussion, a pg_dump dump now conforms to the standard_conforming_strings setting of the source database. We don't use E'' syntax in the dump, thereby improving portability of the SQL. I added a SET escape_strings_warning = off command to keep the dumps from getting a lot of back-chatter from that.
2006-05-28 23:13:54 +02:00
appendStringInfoChar(buf, ch);
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
}
appendStringInfoChar(buf, '\'');
break;
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
}
pfree(extval);
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Append ::typename unless the constant will be implicitly typed as the
* right type when it is read in. XXX this code has to be kept in sync
* with the behavior of the parser, especially make_const.
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
*/
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
switch (constval->consttype)
{
Make pg_dump output more portable and more pleasing to look at. The -n and -N options were removed. Quoting is now smart enough to supply quotes if and only if necessary. Numerical types are now printed without quotes, except in cases of special values such as NaN. Boolean values printed as true and false. Most string literals now do not escape whitespace characters (newlines, etc.) for portability. SET SESSION AUTHORIZATION argument is a string literal, to follow SQL. Made commands output by pg_dump use consistent spacing and indentation.
2002-08-18 11:36:26 +02:00
case BOOLOID:
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
case INT4OID:
case UNKNOWNOID:
/* These types can be left unlabeled */
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
needlabel = false;
break;
case NUMERICOID:
/* Float-looking constants will be typed as numeric */
needlabel = !isfloat;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
break;
default:
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
needlabel = true;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
break;
}
Extend pg_cast castimplicit column to a three-way value; this allows us to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
2002-09-18 23:35:25 +02:00
if (needlabel)
appendStringInfo(buf, "::%s",
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
format_type_with_typemod(constval->consttype, -1));
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
/* ----------
* get_sublink_expr - Parse back a sublink
* ----------
*/
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
static void
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
get_sublink_expr(SubLink *sublink, deparse_context *context)
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Reimplement parsing and storage of default expressions and constraint expressions in CREATE TABLE. There is no longer an emasculated expression syntax for these things; it's full a_expr for constraints, and b_expr for defaults (unfortunately the fact that NOT NULL is a part of the column constraint syntax causes a shift/reduce conflict if you try a_expr. Oh well --- at least parenthesized boolean expressions work now). Also, stored expression for a column default is not pre-coerced to the column type; we rely on transformInsertStatement to do that when the default is actually used. This means "f1 datetime default 'now'" behaves the way people usually expect it to. BTW, all the support code is now there to implement ALTER TABLE ADD CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't actually teach ALTER TABLE to call it, but it wouldn't be much work.
1999-10-04 01:55:40 +02:00
StringInfo buf = context->buf;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
Query *query = (Query *) (sublink->subselect);
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
char *opname = NULL;
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
bool need_paren;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
if (sublink->subLinkType == ARRAY_SUBLINK)
appendStringInfo(buf, "ARRAY(");
else
appendStringInfoChar(buf, '(');
Fix several problems in rule deparsing: didn't handle array references or CASE expressions, didn't parenthesize complex expressions properly. Also, always output variable references as fully qualified names to eliminate ambiguity bug recently reported. (This could be smarter, but reliability comes first.)
1999-08-28 05:59:05 +02:00
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
/*
* Note that we print the name of only the first operator, when there
* are multiple combining operators. This is an approximation that
* could go wrong in various scenarios (operators in different schemas,
* renamed operators, etc) but there is not a whole lot we can do about
* it, since the syntax allows only one operator to be shown.
*/
if (sublink->testexpr)
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
{
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
if (IsA(sublink->testexpr, OpExpr))
{
/* single combining operator */
OpExpr *opexpr = (OpExpr *) sublink->testexpr;
get_rule_expr(linitial(opexpr->args), context, true);
opname = generate_operator_name(opexpr->opno,
exprType(linitial(opexpr->args)),
exprType(lsecond(opexpr->args)));
}
else if (IsA(sublink->testexpr, BoolExpr))
{
/* multiple combining operators, = or <> cases */
char *sep;
ListCell *l;
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
appendStringInfoChar(buf, '(');
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
sep = "";
foreach(l, ((BoolExpr *) sublink->testexpr)->args)
{
OpExpr *opexpr = (OpExpr *) lfirst(l);
Assert(IsA(opexpr, OpExpr));
appendStringInfoString(buf, sep);
get_rule_expr(linitial(opexpr->args), context, true);
if (!opname)
opname = generate_operator_name(opexpr->opno,
exprType(linitial(opexpr->args)),
exprType(lsecond(opexpr->args)));
sep = ", ";
}
Change get_rule_expr so that when the input is a List, it displays the list elements comma-separated instead of barfing. This allows elimination of half a dozen redundant copies of that behavior, and also makes the world safe again for pg_get_expr() applied to pg_index.indexprs, per gripe from Alexander Zhiltsov.
2004-10-07 22:36:52 +02:00
appendStringInfoChar(buf, ')');
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
}
else if (IsA(sublink->testexpr, RowCompareExpr))
{
/* multiple combining operators, < <= > >= cases */
RowCompareExpr *rcexpr = (RowCompareExpr *) sublink->testexpr;
appendStringInfoChar(buf, '(');
get_rule_expr((Node *) rcexpr->largs, context, true);
opname = generate_operator_name(linitial_oid(rcexpr->opnos),
exprType(linitial(rcexpr->largs)),
exprType(linitial(rcexpr->rargs)));
appendStringInfoChar(buf, ')');
}
else
elog(ERROR, "unrecognized testexpr type: %d",
(int) nodeTag(sublink->testexpr));
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
}
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
need_paren = true;
pgindent run over code.
1999-05-25 18:15:34 +02:00
switch (sublink->subLinkType)
{
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
case EXISTS_SUBLINK:
Revise rule-printing routines to use expandable StringInfo buffers, so that they have no hardwired limit on the length of a rule's text. Fix a couple of minor bugs in passing --- deparsed UPDATE queries didn't have quotes around relation name, and quotes and backslashes in constant values weren't backslash-quoted.
1999-10-02 03:08:05 +02:00
appendStringInfo(buf, "EXISTS ");
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
break;
case ANY_SUBLINK:
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
if (strcmp(opname, "=") == 0) /* Represent = ANY as IN */
appendStringInfo(buf, " IN ");
Adjust parser so that 'x NOT IN (subselect)' is converted to 'NOT (x IN (subselect))', that is 'NOT (x = ANY (subselect))', rather than 'x <> ALL (subselect)' as we formerly did. This opens the door to optimizing NOT IN the same way as IN, whereas there's no hope of optimizing the expression using <>. Also, convert 'x <> ALL (subselect)' to the NOT(IN) style, so that the optimization will be available when processing rules dumped by older Postgres versions. initdb forced due to small change in SubLink node representation.
2003-01-09 21:50:53 +01:00
else
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
appendStringInfo(buf, " %s ANY ", opname);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
break;
case ALL_SUBLINK:
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
appendStringInfo(buf, " %s ALL ", opname);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
break;
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
case ROWCOMPARE_SUBLINK:
appendStringInfo(buf, " %s ", opname);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
break;
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
case EXPR_SUBLINK:
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
case ARRAY_SUBLINK:
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
need_paren = false;
break;
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized sublink type: %d",
(int) sublink->subLinkType);
Here's a combination of all the patches I'm currently waiting for against a just updated CVS tree. It contains Partial new rewrite system that handles subselects, view aggregate columns, insert into select from view, updates with set col = view-value and select rules restriction to view definition. Updates for rule/view backparsing utility functions to handle subselects correct. New system views pg_tables and pg_indexes (where you can see the complete index definition in the latter one). Enabling array references on query parameters. Bugfix for functional index. Little changes to system views pg_rules and pg_views. The rule system isn't a release-stopper any longer. But another stopper is that I don't know if the latest changes to PL/pgSQL (not already in CVS) made it compile on AIX. Still wait for some response from Dave. Jan
1998-10-02 18:28:04 +02:00
break;
}
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
if (need_paren)
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
appendStringInfoChar(buf, '(');
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
get_query_def(query, buf, context->namespaces, NULL,
context->prettyFlags, context->indentLevel);
Implement subselects in target lists. Also, relax requirement that subselects can only appear on the righthand side of a binary operator. That's still true for quantified predicates like x = ANY (SELECT ...), but a subselect that delivers a single result can now appear anywhere in an expression. This is implemented by changing EXPR_SUBLINK sublinks to represent just the (SELECT ...) expression, without any 'left hand side' or combining operator --- so they're now more like EXISTS_SUBLINK. To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to. But the grammar will only generate one for a multiple-left-hand-side row expression.
1999-11-15 03:00:15 +01:00
if (need_paren)
appendStringInfo(buf, "))");
else
Create a new expression node type RelabelType, which exists solely to represent the result of a binary-compatible type coercion. At runtime it just evaluates its argument --- but during type resolution, exprType will pick up the output type of the RelabelType node instead of the type of the argument. This solves some longstanding problems with dropped type coercions, an example being 'select now()::abstime::int4' which used to produce date-formatted output, not an integer, because the coercion to int4 was dropped on the floor.
2000-02-20 22:32:16 +01:00
appendStringInfoChar(buf, ')');
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
/* ----------
* get_from_clause - Parse back a FROM clause
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
*
* "prefix" is the keyword that denotes the start of the list of FROM
* elements. It is FROM when used to parse back SELECT and UPDATE, but
* is USING when parsing back DELETE.
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
* ----------
*/
static void
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
get_from_clause(Query *query, const char *prefix, deparse_context *context)
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
{
StringInfo buf = context->buf;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
bool first = true;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We use the query's jointree as a guide to what to print. However, we
* must ignore auto-added RTEs that are marked not inFromCl. (These can
* only appear at the top level of the jointree, so it's sufficient to
* check here.) This check also ensures we ignore the rule pseudo-RTEs
* for NEW and OLD.
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
*/
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
foreach(l, query->jointree->fromlist)
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
{
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Node *jtnode = (Node *) lfirst(l);
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
if (IsA(jtnode, RangeTblRef))
{
int varno = ((RangeTblRef *) jtnode)->rtindex;
RangeTblEntry *rte = rt_fetch(varno, query->rtable);
if (!rte->inFromCl)
continue;
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (first)
{
Add a "USING" clause to DELETE, which is equivalent to the FROM clause in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
2005-04-07 03:51:41 +02:00
appendContextKeyword(context, prefix,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
-PRETTYINDENT_STD, PRETTYINDENT_STD, 2);
first = false;
}
else
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoString(buf, ", ");
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
get_from_clause_item(jtnode, query, context);
}
}
static void
get_from_clause_item(Node *jtnode, Query *query, deparse_context *context)
{
StringInfo buf = context->buf;
if (IsA(jtnode, RangeTblRef))
{
int varno = ((RangeTblRef *) jtnode)->rtindex;
RangeTblEntry *rte = rt_fetch(varno, query->rtable);
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
bool gavealias = false;
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
switch (rte->rtekind)
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
{
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
case RTE_RELATION:
/* Normal relation RTE */
appendStringInfo(buf, "%s%s",
only_marker(rte),
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
generate_relation_name(rte->relid));
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
break;
case RTE_SUBQUERY:
/* Subquery RTE */
appendStringInfoChar(buf, '(');
pgindent run.
2003-08-04 02:43:34 +02:00
get_query_def(rte->subquery, buf, context->namespaces, NULL,
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context->prettyFlags, context->indentLevel);
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
appendStringInfoChar(buf, ')');
break;
First pass at set-returning-functions in FROM, by Joe Conway with some kibitzing from Tom Lane. Not everything works yet, and there's no documentation or regression test, but let's commit this so Joe doesn't need to cope with tracking changes in so many files ...
2002-05-12 22:10:05 +02:00
case RTE_FUNCTION:
/* Function RTE */
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(rte->funcexpr, context, true);
First pass at set-returning-functions in FROM, by Joe Conway with some kibitzing from Tom Lane. Not everything works yet, and there's no documentation or regression test, but let's commit this so Joe doesn't need to cope with tracking changes in so many files ...
2002-05-12 22:10:05 +02:00
break;
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized RTE kind: %d", (int) rte->rtekind);
A little further progress on schemas: push down RangeVars into addRangeTableEntry calls. Remove relname field from RTEs, since it will no longer be a useful unique identifier of relations; we want to encourage people to rely on the relation OID instead. Further work on dumping qual expressions in EXPLAIN, too.
2002-03-22 03:56:37 +01:00
break;
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias. (Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
2000-09-29 20:21:41 +02:00
}
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
if (rte->alias != NULL)
{
appendStringInfo(buf, " %s",
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
quote_identifier(rte->alias->aliasname));
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
gavealias = true;
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
else if (rte->rtekind == RTE_RELATION &&
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
strcmp(rte->eref->aliasname, get_rel_name(rte->relid)) != 0)
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Apparently the rel has been renamed since the rule was made.
* Emit a fake alias clause so that variable references will still
* work. This is not a 100% solution but should work in most
* reasonable situations.
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
*/
appendStringInfo(buf, " %s",
quote_identifier(rte->eref->aliasname));
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
gavealias = true;
}
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
else if (rte->rtekind == RTE_FUNCTION)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* For a function RTE, always give an alias. This covers possible
* renaming of the function and/or instability of the
* FigureColname rules for things that aren't simple functions.
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
*/
appendStringInfo(buf, " %s",
quote_identifier(rte->eref->aliasname));
gavealias = true;
}
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
if (rte->rtekind == RTE_FUNCTION)
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
{
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
if (rte->funccoltypes != NIL)
{
/* Function returning RECORD, reconstruct the columndefs */
if (!gavealias)
appendStringInfo(buf, " AS ");
get_from_clause_coldeflist(rte->eref->colnames,
rte->funccoltypes,
rte->funccoltypmods,
context);
}
else
{
/*
* For a function RTE, always emit a complete column alias
* list; this is to protect against possible instability of
* the default column names (eg, from altering parameter
* names).
*/
get_from_clause_alias(rte->eref, rte, context);
}
Cause view/rule display to work as expected after rename of an underlying table or column, or of an output column of the view itself.
2002-08-08 19:00:19 +02:00
}
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
else
{
/*
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
* For non-function RTEs, just report whatever the user originally
* gave as column aliases.
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
*/
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
get_from_clause_alias(rte->alias, rte, context);
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
else if (IsA(jtnode, JoinExpr))
{
JoinExpr *j = (JoinExpr *) jtnode;
pgindent run.
2003-08-04 02:43:34 +02:00
bool need_paren_on_right;
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
need_paren_on_right = PRETTY_PAREN(context) &&
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
!IsA(j->rarg, RangeTblRef) &&
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
!(IsA(j->rarg, JoinExpr) &&((JoinExpr *) j->rarg)->alias != NULL);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context) || j->alias != NULL)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
get_from_clause_item(j->larg, query, context);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
if (j->isNatural)
{
pgindent run.
2003-08-04 02:43:34 +02:00
if (!PRETTY_INDENT(context))
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfoChar(buf, ' ');
pgindent run.
2003-08-04 02:43:34 +02:00
switch (j->jointype)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case JOIN_INNER:
NATURAL CROSS JOIN is a contradiction in terms, not to mention disallowed by the SQL spec and by our parser. Thanks to Jonathan Scott for finding this longstanding error.
2004-05-07 05:19:44 +02:00
appendContextKeyword(context, "NATURAL JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 0);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
break;
case JOIN_LEFT:
appendContextKeyword(context, "NATURAL LEFT JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 0);
break;
case JOIN_FULL:
appendContextKeyword(context, "NATURAL FULL JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 0);
break;
case JOIN_RIGHT:
appendContextKeyword(context, "NATURAL RIGHT JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 0);
break;
default:
elog(ERROR, "unrecognized join type: %d",
(int) j->jointype);
pgindent run.
2003-08-04 02:43:34 +02:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
}
else
{
pgindent run.
2003-08-04 02:43:34 +02:00
switch (j->jointype)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
case JOIN_INNER:
if (j->quals)
appendContextKeyword(context, " JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 2);
else
appendContextKeyword(context, " CROSS JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 1);
break;
case JOIN_LEFT:
appendContextKeyword(context, " LEFT JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 2);
break;
case JOIN_FULL:
appendContextKeyword(context, " FULL JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 2);
break;
case JOIN_RIGHT:
appendContextKeyword(context, " RIGHT JOIN ",
-PRETTYINDENT_JOIN,
PRETTYINDENT_JOIN, 2);
break;
default:
elog(ERROR, "unrecognized join type: %d",
(int) j->jointype);
pgindent run.
2003-08-04 02:43:34 +02:00
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (need_paren_on_right)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
get_from_clause_item(j->rarg, query, context);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (need_paren_on_right)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
context->indentLevel -= PRETTYINDENT_JOIN_ON;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
if (!j->isNatural)
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
{
if (j->using)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *col;
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
appendStringInfo(buf, " USING (");
foreach(col, j->using)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
if (col != list_head(j->using))
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
appendStringInfo(buf, ", ");
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(buf,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
quote_identifier(strVal(lfirst(col))));
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
appendStringInfoChar(buf, ')');
}
else if (j->quals)
{
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
appendStringInfo(buf, " ON ");
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, '(');
Department of second thoughts: suppressing implicit casts everywhere in ruleutils display is not such a great idea. For arguments of functions and operators I think we'd better keep the historical behavior of showing such casts explicitly, to ensure that the function/operator is reparsed the same way when the rule is reloaded. This also makes the output of EXPLAIN less obscurantist about exactly what's happening.
2002-09-20 00:48:34 +02:00
get_rule_expr(j->quals, context, false);
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context))
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
}
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
if (!PRETTY_PAREN(context) || j->alias != NULL)
pgindent run.
2003-08-04 02:43:34 +02:00
appendStringInfoChar(buf, ')');
Add pretty-printing variants of pg_get_viewdef and related functions. Patch from Andreas Pflug.
2003-07-31 00:56:24 +02:00
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
/* Yes, it's correct to put alias after the right paren ... */
if (j->alias != NULL)
{
appendStringInfo(buf, " %s",
First phase of SCHEMA changes, concentrating on fixing the grammar and the parsetree representation. As yet we don't *do* anything with schema names, just drop 'em on the floor; but you can enter schema-compatible command syntax, and there's even a primitive CREATE SCHEMA command. No doc updates yet, except to note that you can now extract a field from a function-returning-row's result with (foo(...)).fieldname.
2002-03-21 17:02:16 +01:00
quote_identifier(j->alias->aliasname));
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
get_from_clause_alias(j->alias,
rt_fetch(j->rtindex, query->rtable),
context);
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
}
else
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized node type: %d",
(int) nodeTag(jtnode));
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
}
Repair some issues with column aliases and RowExpr construction in the presence of dropped columns. Document the already-presumed fact that eref aliases in relation RTEs are supposed to have entries for dropped columns; cause the user alias structs to have such entries too, so that there's always a one-to-one mapping to the underlying physical attnums. Adjust expandRTE() and related code to handle the case where a column that is part of a JOIN has been dropped. Generalize expandRTE()'s API so that it can be used in a couple of places that formerly rolled their own implementation of the same logic. Fix ruleutils.c to suppress display of aliases for columns that were dropped since the rule was made.
2004-08-19 22:57:41 +02:00
/*
* get_from_clause_alias - reproduce column alias list
*
* This is tricky because we must ignore dropped columns.
*/
static void
When a function not returning RECORD has a single OUT parameter, use the parameter's name (if any) as the default column name for SELECT FROM the function, rather than the function name as previously. I still think this is a bad idea, but I lost the argument. Force decompilation of function RTEs to specify full aliases always, to reduce the odds of this decision breaking dumped views.
2005-10-06 21:51:16 +02:00
get_from_clause_alias(Alias *alias, RangeTblEntry *rte,
deparse_context *context)
Repair some issues with column aliases and RowExpr construction in the presence of dropped columns. Document the already-presumed fact that eref aliases in relation RTEs are supposed to have entries for dropped columns; cause the user alias structs to have such entries too, so that there's always a one-to-one mapping to the underlying physical attnums. Adjust expandRTE() and related code to handle the case where a column that is part of a JOIN has been dropped. Generalize expandRTE()'s API so that it can be used in a couple of places that formerly rolled their own implementation of the same logic. Fix ruleutils.c to suppress display of aliases for columns that were dropped since the rule was made.
2004-08-19 22:57:41 +02:00
{
StringInfo buf = context->buf;
ListCell *col;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
AttrNumber attnum;
Repair some issues with column aliases and RowExpr construction in the presence of dropped columns. Document the already-presumed fact that eref aliases in relation RTEs are supposed to have entries for dropped columns; cause the user alias structs to have such entries too, so that there's always a one-to-one mapping to the underlying physical attnums. Adjust expandRTE() and related code to handle the case where a column that is part of a JOIN has been dropped. Generalize expandRTE()'s API so that it can be used in a couple of places that formerly rolled their own implementation of the same logic. Fix ruleutils.c to suppress display of aliases for columns that were dropped since the rule was made.
2004-08-19 22:57:41 +02:00
bool first = true;
if (alias == NULL || alias->colnames == NIL)
return; /* definitely nothing to do */
attnum = 0;
foreach(col, alias->colnames)
{
attnum++;
Revise handling of dropped columns in JOIN alias lists to avoid a performance problem pointed out by phil@vodafone: to wit, we were spending O(N^2) time to check dropped-ness in an N-deep join tree, even in the case where the tree was freshly constructed and couldn't possibly mention any dropped columns. Instead of recursing in get_rte_attribute_is_dropped(), change the data structure definition: the joinaliasvars list of a JOIN RTE must have a NULL Const instead of a Var at any position that references a now-dropped column. This costs nothing during normal parse-rewrite-plan path, and instead we have a linear-time update to make when loading a stored rule that might contain now-dropped columns. While at it, move the responsibility for acquring locks on relations referenced by rules into this separate function (which I therefore chose to call AcquireRewriteLocks). This saves effort --- namely, duplicated lock grabs in parser and rewriter --- in the normal path at a cost of one extra non-locked heap_open() in the stored-rule path; seems a good tradeoff. A fringe benefit is that it is now *much* clearer that we acquire lock on relations referenced in rules before we make any rewriter decisions based on their properties. (I don't know of any bug of that ilk, but it wasn't exactly clear before.)
2005-06-04 01:05:30 +02:00
if (get_rte_attribute_is_dropped(rte, attnum))
Repair some issues with column aliases and RowExpr construction in the presence of dropped columns. Document the already-presumed fact that eref aliases in relation RTEs are supposed to have entries for dropped columns; cause the user alias structs to have such entries too, so that there's always a one-to-one mapping to the underlying physical attnums. Adjust expandRTE() and related code to handle the case where a column that is part of a JOIN has been dropped. Generalize expandRTE()'s API so that it can be used in a couple of places that formerly rolled their own implementation of the same logic. Fix ruleutils.c to suppress display of aliases for columns that were dropped since the rule was made.
2004-08-19 22:57:41 +02:00
continue;
if (first)
{
appendStringInfoChar(buf, '(');
first = false;
}
else
appendStringInfo(buf, ", ");
appendStringInfoString(buf,
quote_identifier(strVal(lfirst(col))));
}
if (!first)
appendStringInfoChar(buf, ')');
}
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
/*
* get_from_clause_coldeflist - reproduce FROM clause coldeflist
*
* The coldeflist is appended immediately (no space) to buf. Caller is
* responsible for ensuring that an alias or AS is present before it.
*/
static void
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
get_from_clause_coldeflist(List *names, List *types, List *typmods,
deparse_context *context)
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
{
StringInfo buf = context->buf;
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
ListCell *l1;
ListCell *l2;
ListCell *l3;
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
int i = 0;
appendStringInfoChar(buf, '(');
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
l2 = list_head(types);
l3 = list_head(typmods);
foreach(l1, names)
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
{
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
char *attname = strVal(lfirst(l1));
Oid atttypid;
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
int32 atttypmod;
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
atttypid = lfirst_oid(l2);
l2 = lnext(l2);
atttypmod = lfirst_int(l3);
l3 = lnext(l3);
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
if (i > 0)
appendStringInfo(buf, ", ");
appendStringInfo(buf, "%s %s",
quote_identifier(attname),
Clean up representation of function RTEs for functions returning RECORD. The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
2006-03-16 01:31:55 +01:00
format_type_with_typemod(atttypid, atttypmod));
Fix ruleutils to dump column definition lists for anonymous record types defined in the FROM clause. From Joe Conway, with some tweaks.
2002-08-29 03:19:41 +02:00
i++;
}
appendStringInfoChar(buf, ')');
}
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
* get_opclass_name - fetch name of an index operator class
*
* The opclass name is appended (after a space) to buf.
Ooops, I was a little too enthusiastic about suppressing default index opclasses; they might be default for some other datatype, in which case we mustn't suppress 'em.
2001-10-05 00:00:10 +02:00
*
* Output is suppressed if the opclass is the default for the given
* actual_datatype. (If you don't want this behavior, just pass
* InvalidOid for actual_datatype.)
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
*/
static void
Ooops, I was a little too enthusiastic about suppressing default index opclasses; they might be default for some other datatype, in which case we mustn't suppress 'em.
2001-10-05 00:00:10 +02:00
get_opclass_name(Oid opclass, Oid actual_datatype,
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
StringInfo buf)
{
HeapTuple ht_opc;
Form_pg_opclass opcrec;
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
char *opcname;
char *nspname;
When dumping CREATE INDEX, must show opclass name if the opclass isn't in the schema search path. Otherwise pg_dump doesn't correctly dump scenarios where a custom opclass is created in 'public' and then used by indexes in other schemas.
2003-10-03 00:24:54 +02:00
bool isvisible;
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
Make domain types indexable. Rod Taylor & Tom Lane.
2002-08-16 22:55:09 +02:00
/* Domains use their base type's default opclass */
if (OidIsValid(actual_datatype))
actual_datatype = getBaseType(actual_datatype);
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
ht_opc = SearchSysCache(CLAOID,
ObjectIdGetDatum(opclass),
0, 0, 0);
if (!HeapTupleIsValid(ht_opc))
elog(ERROR, "cache lookup failed for opclass %u", opclass);
opcrec = (Form_pg_opclass) GETSTRUCT(ht_opc);
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Special case for ARRAY_OPS: pretend it is default for any array type
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
Create a 'type cache' that keeps track of the data needed for any particular datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
2003-08-17 21:58:06 +02:00
if (OidIsValid(actual_datatype))
{
if (opcrec->opcintype == ANYARRAYOID &&
OidIsValid(get_element_type(actual_datatype)))
actual_datatype = opcrec->opcintype;
}
When dumping CREATE INDEX, must show opclass name if the opclass isn't in the schema search path. Otherwise pg_dump doesn't correctly dump scenarios where a custom opclass is created in 'public' and then used by indexes in other schemas.
2003-10-03 00:24:54 +02:00
/* Must force use of opclass name if not in search path */
isvisible = OpclassIsVisible(opclass);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
When dumping CREATE INDEX, must show opclass name if the opclass isn't in the schema search path. Otherwise pg_dump doesn't correctly dump scenarios where a custom opclass is created in 'public' and then used by indexes in other schemas.
2003-10-03 00:24:54 +02:00
if (actual_datatype != opcrec->opcintype || !opcrec->opcdefault ||
!isvisible)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
{
pgindent run.
2002-09-04 22:31:48 +02:00
/* Okay, we need the opclass name. Do we need to qualify it? */
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
opcname = NameStr(opcrec->opcname);
When dumping CREATE INDEX, must show opclass name if the opclass isn't in the schema search path. Otherwise pg_dump doesn't correctly dump scenarios where a custom opclass is created in 'public' and then used by indexes in other schemas.
2003-10-03 00:24:54 +02:00
if (isvisible)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
appendStringInfo(buf, " %s", quote_identifier(opcname));
else
{
nspname = get_namespace_name(opcrec->opcnamespace);
appendStringInfo(buf, " %s.%s",
quote_identifier(nspname),
quote_identifier(opcname));
}
}
Extend pg_get_indexdef() to know about index predicates. Also, tweak it to suppress index opclass output for opclasses that are the default for their datatype; only non-default opclasses are shown explicitly. This is expected to improve portability of the CREATE INDEX command across future versions of Postgres --- we've changed index opclasses too often in the past to think we won't do so again.
2001-10-01 22:15:26 +02:00
ReleaseSysCache(ht_opc);
}
First cut at full support for OUTER JOINs. There are still a few loose ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
2000-09-12 23:07:18 +02:00
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
* processIndirection - take care of array and subfield assignment
*
* We strip any top-level FieldStore or assignment ArrayRef nodes that
* appear in the input, printing out the appropriate decoration for the
* base column name (that the caller just printed). We return the
* subexpression that's to be assigned.
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
*/
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
static Node *
processIndirection(Node *node, deparse_context *context)
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
{
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
StringInfo buf = context->buf;
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
for (;;)
{
if (node == NULL)
break;
if (IsA(node, FieldStore))
{
FieldStore *fstore = (FieldStore *) node;
Oid typrelid;
char *fieldname;
/* lookup tuple type */
typrelid = get_typ_typrelid(fstore->resulttype);
if (!OidIsValid(typrelid))
elog(ERROR, "argument type %s of FieldStore is not a tuple type",
format_type_be(fstore->resulttype));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Get the field name. Note we assume here that there's only one
* field being assigned to. This is okay in stored rules but
* could be wrong in executable target lists. Presently no
* problem since explain.c doesn't print plan targetlists, but
* someday may have to think of something ...
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
fieldname = get_relid_attribute_name(typrelid,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
linitial_int(fstore->fieldnums));
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
appendStringInfo(buf, ".%s", quote_identifier(fieldname));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We ignore arg since it should be an uninteresting reference to
* the target column or subcolumn.
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
node = (Node *) linitial(fstore->newvals);
}
else if (IsA(node, ArrayRef))
{
ArrayRef *aref = (ArrayRef *) node;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
if (aref->refassgnexpr == NULL)
break;
printSubscripts(aref, context);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We ignore refexpr since it should be an uninteresting reference
* to the target column or subcolumn.
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
*/
node = (Node *) aref->refassgnexpr;
}
else
break;
}
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
return node;
}
static void
printSubscripts(ArrayRef *aref, deparse_context *context)
{
StringInfo buf = context->buf;
ListCell *lowlist_item;
ListCell *uplist_item;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
lowlist_item = list_head(aref->reflowerindexpr); /* could be NULL */
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
foreach(uplist_item, aref->refupperindexpr)
{
appendStringInfoChar(buf, '[');
if (lowlist_item)
{
get_rule_expr((Node *) lfirst(lowlist_item), context, false);
appendStringInfoChar(buf, ':');
lowlist_item = lnext(lowlist_item);
}
get_rule_expr((Node *) lfirst(uplist_item), context, false);
appendStringInfoChar(buf, ']');
}
Fix ruleutils to produce correct output for array assignment, such as UPDATE foo SET arr[3] = 42.
2000-08-12 06:04:53 +02:00
}
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
* quote_identifier - Quote an identifier only if needed
*
* When quotes are needed, we palloc the required space; slightly
* space-wasteful but well worth it for notational simplicity.
*/
Implement types regprocedure, regoper, regoperator, regclass, regtype per pghackers discussion. Add some more typsanity tests, and clean up some problems exposed thereby (broken or missing array types for some built-in types). Also, clean up loose ends from unknownin/out patch.
2002-04-25 04:56:56 +02:00
const char *
quote_identifier(const char *ident)
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Can avoid quoting if ident starts with a lowercase letter or underscore
* and contains only lowercase letters, digits, and underscores, *and* is
* not any SQL keyword. Otherwise, supply quotes.
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
*/
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
int nquotes = 0;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
bool safe;
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
const char *ptr;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
char *result;
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
char *optr;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* would like to use <ctype.h> macros here, but they might yield unwanted
* locale-specific results...
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
*/
Make ruleutils.c use format_type for printing typenames. Minor tweaks in quoting rules and recognition of implicit type coercions.
2002-04-28 02:49:13 +02:00
safe = ((ident[0] >= 'a' && ident[0] <= 'z') || ident[0] == '_');
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
for (ptr = ident; *ptr; ptr++)
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
{
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
char ch = *ptr;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
if ((ch >= 'a' && ch <= 'z') ||
(ch >= '0' && ch <= '9') ||
(ch == '_'))
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
{
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
/* okay */
}
else
{
safe = false;
if (ch == '"')
nquotes++;
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
}
}
Rule deparser needs to quote identifiers that are spelled the same as SQL keywords.
1999-12-06 03:37:17 +01:00
if (safe)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check for keyword. This test is overly strong, since many of the
* "keywords" known to the parser are usable as column names, but the
* parser doesn't provide any easy way to test for whether an
* identifier is safe or not... so be safe not sorry.
Rule deparser needs to quote identifiers that are spelled the same as SQL keywords.
1999-12-06 03:37:17 +01:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* Note: ScanKeywordLookup() does case-insensitive comparison, but
* that's fine, since we already know we have all-lower-case.
Rule deparser needs to quote identifiers that are spelled the same as SQL keywords.
1999-12-06 03:37:17 +01:00
*/
Tweak scanner/grammar interface so that the keyword-as-identifier rules in gram.y can make use of the keywords.c string table, instead of having their own copies of the keyword strings. This saves a few kilobytes and more importantly eliminates an opportunity for cut-and-paste errors.
2002-05-02 20:44:11 +02:00
if (ScanKeywordLookup(ident) != NULL)
Rule deparser needs to quote identifiers that are spelled the same as SQL keywords.
1999-12-06 03:37:17 +01:00
safe = false;
}
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
if (safe)
return ident; /* no change needed */
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
result = (char *) palloc(strlen(ident) + nquotes + 2 + 1);
optr = result;
*optr++ = '"';
for (ptr = ident; *ptr; ptr++)
{
char ch = *ptr;
if (ch == '"')
*optr++ = '"';
*optr++ = ch;
}
*optr++ = '"';
*optr = '\0';
Make the rule deparser a little less quote-happy, so that display of default expressions isn't quite so ugly.
1999-10-04 06:37:23 +02:00
return result;
}
This is the final state of the rule system for 6.4 after the patch is applied: Rewrite rules on relation level work fine now. Event qualifications on insert/update/delete rules work fine now. I added the new keyword OLD to reference the CURRENT tuple. CURRENT will be removed in 6.5. Update rules can reference NEW and OLD in the rule qualification and the actions. Insert/update/delete rules on views can be established to let them behave like real tables. For insert/update/delete rules multiple actions are supported now. The actions can also be surrounded by parantheses to make psql happy. Multiple actions are required if update to a view requires updates to multiple tables. Regular users are permitted to create/drop rules on tables they have RULE permissions for (DefineQueryRewrite() is now able to get around the access restrictions on pg_rewrite). This enables view creation for regular users too. This required an extra boolean parameter to pg_parse_and_plan() that tells to set skipAcl on all rangetable entries of the resulting queries. There is a new function pg_exec_query_acl_override() that could be used by backend utilities to use this facility. All rule actions (not only views) inherit the permissions of the event relations owner. Sample: User A creates tables T1 and T2, creates rules that log INSERT/UPDATE/DELETE on T1 in T2 (like in the regression tests for rules I created) and grants ALL but RULE on T1 to user B. User B can now fully access T1 and the logging happens in T2. But user B cannot access T2 at all, only the rule actions can. And due to missing RULE permissions on T1, user B cannot disable logging. Rules on the attribute level are disabled (they don't work properly and since regular users are now permitted to create rules I decided to disable them). Rules on select must have exactly one action that is a select (so select rules must be a view definition). UPDATE NEW/OLD rules are disabled (still broken, but triggers can do it). There are two new system views (pg_rule and pg_view) that show the definition of the rules or views so the db admin can see what the users do. They use two new functions pg_get_ruledef() and pg_get_viewdef() that are builtins. The functions pg_get_ruledef() and pg_get_viewdef() could be used to implement rule and view support in pg_dump. PostgreSQL is now the only database system I know, that has rewrite rules on the query level. All others (where I found a rule statement at all) use stored database procedures or the like (triggers as we call them) for active rules (as some call them). Future of the rule system: The now disabled parts of the rule system (attribute level, multiple actions on select and update new stuff) require a complete new rewrite handler from scratch. The old one is too badly wired up. After 6.4 I'll start to work on a new rewrite handler, that fully supports the attribute level rules, multiple actions on select and update new. This will be available for 6.5 so we get full rewrite rule capabilities. Jan
1998-08-24 03:38:11 +02:00
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
Implement types regprocedure, regoper, regoperator, regclass, regtype per pghackers discussion. Add some more typsanity tests, and clean up some problems exposed thereby (broken or missing array types for some built-in types). Also, clean up loose ends from unknownin/out patch.
2002-04-25 04:56:56 +02:00
* quote_qualified_identifier - Quote a possibly-qualified identifier
*
* Return a name of the form namespace.ident, or just ident if namespace
* is NULL, quoting each component if necessary. The result is palloc'd.
*/
char *
quote_qualified_identifier(const char *namespace,
const char *ident)
{
StringInfoData buf;
initStringInfo(&buf);
if (namespace)
appendStringInfo(&buf, "%s.", quote_identifier(namespace));
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(&buf, quote_identifier(ident));
Implement types regprocedure, regoper, regoperator, regclass, regtype per pghackers discussion. Add some more typsanity tests, and clean up some problems exposed thereby (broken or missing array types for some built-in types). Also, clean up loose ends from unknownin/out patch.
2002-04-25 04:56:56 +02:00
return buf.data;
}
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
/*
* generate_relation_name
* Compute the name to display for a relation specified by OID
*
* The result includes all necessary quoting and schema-prefixing.
*/
static char *
generate_relation_name(Oid relid)
{
HeapTuple tp;
Form_pg_class reltup;
char *nspname;
char *result;
tp = SearchSysCache(RELOID,
ObjectIdGetDatum(relid),
0, 0, 0);
if (!HeapTupleIsValid(tp))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for relation %u", relid);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
reltup = (Form_pg_class) GETSTRUCT(tp);
/* Qualify the name if not visible in search path */
if (RelationIsVisible(relid))
nspname = NULL;
else
nspname = get_namespace_name(reltup->relnamespace);
result = quote_qualified_identifier(nspname, NameStr(reltup->relname));
ReleaseSysCache(tp);
return result;
}
/*
* generate_function_name
* Compute the name to display for a function specified by OID,
* given that it is being called with the specified actual arg types.
* (Arg types matter because of ambiguous-function resolution rules.)
*
* The result includes all necessary quoting and schema-prefixing.
*/
static char *
generate_function_name(Oid funcid, int nargs, Oid *argtypes)
{
HeapTuple proctup;
Form_pg_proc procform;
char *proname;
char *nspname;
char *result;
FuncDetailCode p_result;
Oid p_funcid;
Oid p_rettype;
bool p_retset;
Oid *p_true_typeids;
proctup = SearchSysCache(PROCOID,
ObjectIdGetDatum(funcid),
0, 0, 0);
if (!HeapTupleIsValid(proctup))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for function %u", funcid);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
procform = (Form_pg_proc) GETSTRUCT(proctup);
proname = NameStr(procform->proname);
Assert(nargs == procform->pronargs);
/*
* The idea here is to schema-qualify only if the parser would fail to
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* resolve the correct function given the unqualified func name with the
* specified argtypes.
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
*/
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
p_result = func_get_detail(list_make1(makeString(proname)),
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
NIL, nargs, argtypes,
&p_funcid, &p_rettype,
&p_retset, &p_true_typeids);
Some early work on error message editing. Operator-not-found and function-not-found messages now distinguish the cases no-match and ambiguous-match, and they follow the style guidelines too.
2003-07-04 04:51:34 +02:00
if ((p_result == FUNCDETAIL_NORMAL || p_result == FUNCDETAIL_AGGREGATE) &&
p_funcid == funcid)
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
nspname = NULL;
else
nspname = get_namespace_name(procform->pronamespace);
result = quote_qualified_identifier(nspname, proname);
ReleaseSysCache(proctup);
return result;
}
/*
* generate_operator_name
* Compute the name to display for an operator specified by OID,
* given that it is being called with the specified actual arg types.
* (Arg types matter because of ambiguous-operator resolution rules.
* Pass InvalidOid for unused arg of a unary operator.)
*
* The result includes all necessary quoting and schema-prefixing,
* plus the OPERATOR() decoration needed to use a qualified operator name
* in an expression.
*/
static char *
generate_operator_name(Oid operid, Oid arg1, Oid arg2)
{
StringInfoData buf;
HeapTuple opertup;
Form_pg_operator operform;
char *oprname;
char *nspname;
Operator p_result;
initStringInfo(&buf);
opertup = SearchSysCache(OPEROID,
ObjectIdGetDatum(operid),
0, 0, 0);
if (!HeapTupleIsValid(opertup))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "cache lookup failed for operator %u", operid);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
operform = (Form_pg_operator) GETSTRUCT(opertup);
oprname = NameStr(operform->oprname);
/*
* The idea here is to schema-qualify only if the parser would fail to
pgindent run.
2002-09-04 22:31:48 +02:00
* resolve the correct operator given the unqualified op name with the
* specified argtypes.
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
*/
switch (operform->oprkind)
{
case 'b':
Improve parser so that we can show an error cursor position for errors during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
2006-03-14 23:48:25 +01:00
p_result = oper(NULL, list_make1(makeString(oprname)), arg1, arg2,
true, -1);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
break;
case 'l':
Improve parser so that we can show an error cursor position for errors during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
2006-03-14 23:48:25 +01:00
p_result = left_oper(NULL, list_make1(makeString(oprname)), arg2,
true, -1);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
break;
case 'r':
Improve parser so that we can show an error cursor position for errors during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
2006-03-14 23:48:25 +01:00
p_result = right_oper(NULL, list_make1(makeString(oprname)), arg1,
true, -1);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
break;
default:
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
elog(ERROR, "unrecognized oprkind: %d", operform->oprkind);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
p_result = NULL; /* keep compiler quiet */
break;
}
if (p_result != NULL && oprid(p_result) == operid)
nspname = NULL;
else
{
nspname = get_namespace_name(operform->oprnamespace);
appendStringInfo(&buf, "OPERATOR(%s.", quote_identifier(nspname));
}
Micro-opt: replace calls like appendStringInfo(buf, "%s", str); with appendStringInfoString(buf, str); as the latter form is slightly faster.
2004-01-31 06:09:41 +01:00
appendStringInfoString(&buf, oprname);
Make ruleutils.c schema-aware. Displayed names are schema-qualified only if they would not be found without qualification given the current search path, as per idea from Peter Eisentraut.
2002-05-03 22:15:02 +02:00
if (nspname)
appendStringInfoChar(&buf, ')');
if (p_result != NULL)
ReleaseSysCache(p_result);
ReleaseSysCache(opertup);
return buf.data;
}
ALTER TABLE rewrite. New cool stuff: * ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL spec. A default is implemented by rewriting the table with the new value stored in each row. * ALTER COLUMN TYPE. You can change a column's datatype to anything you want, so long as you can specify how to convert the old value. Rewrites the table. (Possible future improvement: optimize no-op conversions such as varchar(N) to varchar(N+1).) * Multiple ALTER actions in a single ALTER TABLE command. You can perform any number of column additions, type changes, and constraint additions with only one pass over the table contents. Basic documentation provided in ALTER TABLE ref page, but some more docs work is needed. Original patch from Rod Taylor, additional work from Tom Lane.
2004-05-05 06:48:48 +02:00
/*
* Given a C string, produce a TEXT datum.
*
* We assume that the input was palloc'd and may be freed.
*/
static text *
string_to_text(char *str)
{
text *result;
int slen = strlen(str);
int tlen;
tlen = slen + VARHDRSZ;
result = (text *) palloc(tlen);
VARATT_SIZEP(result) = tlen;
memcpy(VARDATA(result), str, slen);
pfree(str);
return result;
}