- 02 8月, 2019 1 次提交
-
-
由 Bhuvnesh Chaudhary 提交于
This commit adds the GPDB side changes required to support GIN Indexes with ORCA. It also adds a new test file gp_gin_indexes to test plans produced for ORCA/planner. GIN indexes are not supported with index expression or predicate constraints. ORCA does not support it currently for other types of indexes too.
-
- 25 7月, 2019 1 次提交
-
-
由 Heikki Linnakangas 提交于
Git stores the 'x' flag for files in the repository. For no good reason, some files had it set differently from upstream. It's harmless, but let's avoid spurious differences.
-
- 23 1月, 2019 1 次提交
-
-
由 Paul Guo 提交于
Remove the obsolete comment for RETURNING and put the test in a parallel running group, following pg upstream.
-
- 11 1月, 2019 1 次提交
-
-
由 Paul Guo 提交于
This feature will not be supported in the oncoming gpdb major release. Explicitly disable it for now.
-
- 28 11月, 2018 1 次提交
-
-
由 Pengzhou Tang 提交于
Recently, ICW case 'select_into' failed intermittently, the error looks like "CREATE TABLE selinto_schema.tmp3 (a,b,c) AS SELECT oid,relname,relacl FROM pg_class WHERE relname like '%c%'; -- OK ERROR: role "30973" does not exist" The RCA is, case 'lock' should not run concurrently with 'select_into', a minirepo is: 1. in 'lock' case CREATE TABLE lock_tbl1 (a BIGINT); CREATE ROLE regress_rol_lock1; GRANT UPDATE ON TABLE lock_tbl1 TO regress_rol_lock1; select oid, relname, relacl from pg_class where relname like '%c%'; oid | relname | relacl --------+-----------+------------------------------------------------------- 180367 | lock_tbl1 | {gpadmin=arwdDxt/gpadmin,regress_rol_lock1=w/gpadmin} 2. in 'select_into' test case CREATE TABLE selinto_schema.tmp3 (a,b,c) AS SELECT oid,relname,relacl FROM pg_class WHERE relname like '%c%'; 3. in 'lock' test case DROP TABLE lock_tbl1; DROP ROLE regress_rol_lock1; 4. in 'select_into' test case select * from tmp3; a | b | c --------+-----------+-------------------------------------------- 180367 | lock_tbl1 | {gpadmin=arwdDxt/gpadmin,180370=w/gpadmin} create table tmp4 as select * from tmp3; NOTICE: Table doesn't have 'DISTRIBUTED BY' clause. Creating a NULL policy entry. ERROR: role "180370" does not exist In Step4, role 'regress_rol_lock1' has been dropped, so when it tries to parse acl, it finds role "180370" does not exist, the error seems to be reasonable. In upstream, test 'lock' doesn't run concurrently with 'select_into', I also notice that we have two 'lock' test within parallel_schedule, so remove the first one to match upstream and avoid the intermittent failure of 'select_into'
-
- 19 11月, 2018 1 次提交
-
-
由 Adam Lee 提交于
This commit adds the support and option of `mpp_execute 'MASTER | ANY | ALL SEGMENTS'` for foreign tables. MASTER is the default, FDW requests for data from master. ANY, FDW requests for data from master or one any segment, depends on which path costs less. ALL SEGMENTS, FDW requests for data from all segments, wrappers need to have a policy matching the segments to data. For instance, file_fdw probes the mpp_execute vaule, then load different files based on the segment number. But something like gpfdist on the foreign side doesn't need this, which hands out a different slice of the data to each request, all segments could request the same location.
-
- 12 11月, 2018 1 次提交
-
-
由 Zhenghua Lyu 提交于
This commit does three things: - move reshufle tests to greenplum_schedule - add cases to test that reshuffle can correctly abort - remove some redundant cases(I think in this regress tests, it is enough to just test expanding from 2 to 3)
-
- 07 11月, 2018 1 次提交
-
-
由 ZhangJackey 提交于
Now we have partial tables and flexible GANG API, so we can allocate GANG according to numsegments. With the commit 4eb65a53, GPDB supports table distributed on partial segments, and with the series of commits (a3ddac06, 576690f2), GPDB supports flexible gang API. Now it is a good time to combine both the new features. The goal is that creating gang only on the necessary segments for each slice. This commit also improves singleQE gang scheduling and does some code clean work. However, if ORCA is enabled, the behavior is just like before. The outline of this commit is: * Modify the FillSliceGangInfo API so that gang_size is truly flexible. * Remove numOutputSegs and outputSegIdx fields in motion node. Add a new field isBroadcast to mark if the motion is a broadcast motion. * Remove the global variable gp_singleton_segindex and make singleQE segment_id randomly(by gp_sess_id). * Remove the field numGangMembersToBeActive in Slice because it is now exactly slice->gangsize. * Modify the message printed if the GUC Test_print_direct_dispatch_info is set. * Explicitly BEGIN create a full gang now. * format and remove destSegIndex * The isReshuffle flag in ModifyTable is useless, because it only is used when we want to insert tuple to the segment which is out the range of the numsegments. Co-authored-by: Zhenghua Lyu zlv@pivotal.io
-
- 23 10月, 2018 1 次提交
-
-
由 ZhangJackey 提交于
Each table has a `numsegments` attribute in the GP_DISTRIBUTION_POLICY table, it indicates that the table's data is distributed on the first N segments, In the common case, the `numsegments` equal the total segment count of this cluster. When we add new segments into the cluster, `numsegments` no longer equal the actual segment count in the cluster, we need to reshuffle the table data to all segments in 2 steps: * Reshuffle the table data to all segments * Update `numsegments` It is easy to update `numsegments`, so we focus on how to reshuffle the table data, There are 3 type tables in the Greenplum database, they are reshuffled in different ways. For the hash distributed table, we reshuffle data based on Update statement. Updating the hash keys of the table ill generate a Plan like: Update ->Redistributed Motion ->SplitUpdate ->SeqScan We can not use this Plan to reshuffle table data directly. The problem is that we need to know the segment count when Motion node computes the destination segment. When we compute the destination segment of deleting tuple, it need the old segment count which is equal `numsegments`; n the other hand, we need to use the new segment count to compute the destination segment for inserting tuple. So we have to add a new operator Reshuffle to compute the destination segment, it records the O and N (O is the count of old segments and N is the count of new segments), then the Plan would be adjusted like: Update ->Explicit Motion ->Reshuffle ->SplitUpdate ->SeqScan It can compute the destination segments directly with O and N, at the same time we change the Motion type to Explicit, it can send a tuple to the destination segment which we computed in the Reshuffle node. With changing the hash method to the `jump hash`, not all the table data need to reshuffle, so we add an new ReshuffleExpr to filter the tuples which are need to reshuffle, this expression will compute the destination segment ahead of schedule, if the destination segment is current segment, the tuple do not need to reshuffle, with the ReshuffleExpr the plan would adjust like that: Update ->Explicit Motion ->Reshuffle ->SplitUpdate ->SeqScan |-ReshuffleExpr When we want to reshuffle one table, we use the SQL `ALTER TABLE xxx SET WITH (RESHUFFLE)`, Actually it will generate an new UpdateStmt parse tree, the parse tree is similar to the parse tree which is generated by SQL `UPDATE xxx SET xxx.aaa = COALESCE(xxx.aaa...) WHERE ReshuffleExpr`. We set an reshuffle flag in the UpdateStmt, so it can distinguish the common update and the reshuffling. In conclusion, we reshuffle hash distributed table by Reshuffle node and ReshuffleExpr, the ReshuffleExpr filter the tuple need to reshuffle and the Reshuffle node do the real reshuffling work, we can use that framework to implement reshuffle random distributed table and replicated table. For random distributed table, it has no hash keys, each old segment need reshuffle (O - N) / N data to the new segments, In the ReshuffleExpr, we can generate a random value between [0, N), if the random values is greater than O, it means that the tuple need to reshuffle, so SeqScan node can return this tuple to ReshuffleNode. Reshuffle node will generate a random value between [O, N), it means which new segment the tuple need to insert. For replicated table, the table data is same in the all old segments, so there do not need to delete any tuples, it only need copy the tuple which is in the old segments to the new segments, so the ReshuffleExpr do not filte any tuples, In the Reshuffle node, we neglect the tuple which is generated for deleting, only return the inserting tuple to motion. Let me illustrate this with an example: If there are 3 old segments in the cluster and we add 4 new segments, the segment ID of old segments is (0,1,2) and the segment ID of new segments is (3,4,5,6), when reshuffle the replicated table, the seg#0 is responsible to copy data to seg#3 and seg#6, the seg#1 is responsible to copy data to seg#4, the seg#2 is responsible to copy data to seg#5. Co-authored-by: Ning Yu nyu@pivotal.io Co-authored-by: Zhenghua Lyu zlv@pivotal.io Co-authored-by: Shujie Zhang shzhang@pivotal.io
-
- 01 10月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
We punted on event triggers during the 9.3 merge. This patches up the OID dispatch of various commands, to make event triggers work, and re-enables the upstream test. In GPDB, event triggers only fire in the QD node, not the segments. That seems like the most sensible behavior. The pg_event_triggers catalog table is not updated in segments, either, it will stay empty. There's one remaining issue, marked with FIXME comments: The pg_event_trigger_dropped_objects() function needs to run in the QD process, or it errors out, but there's no way to force the planner to do that. So if you try to use it as part of a more complicated query, it won't work. One of the upstream tests had to be modified to work around that.
-
- 06 9月, 2018 1 次提交
-
-
由 Taylor Vesely 提交于
In GPDB AGGREGATE functions can be either 'ordered' or 'hypothetical', and as a result the token aggr_args has more information than in upstream. Excepting CREATE [ORDERED] AGGREGATE, the parser will extract the function arguments from the aggr_args token using extractAggrArgTypes(). The ALTER EXTENSION ADD/DROP AGGREGATE and SECURITY LIMIT syntax has been added as part of the merge of PostgreSQL between 9.0 and 9.2, so add a call to extract the function arguments. Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io>
-
- 31 8月, 2018 1 次提交
-
-
由 xiong-gang 提交于
Quite a few cases in 'triggers' don't apply on GPDB: non-SELECT statement in trigger function, modification on views, INSTEAD OF triggers, etc. But we can still use some of the test cases, for example, FOR STATEMENT trigger start acting differently since we changed INSERT/DELETE/UPDATE to modifyTable by merging 8.5, and it should have been caught by the tests.
-
- 03 8月, 2018 1 次提交
-
-
由 Karen Huddleston 提交于
This reverts commit 4750e1b6.
-
- 02 8月, 2018 1 次提交
-
-
由 Richard Guo 提交于
This is the final batch of commits from PostgreSQL 9.2 development, up to the point where the REL9_2_STABLE branch was created, and 9.3 development started on the PostgreSQL master branch. Notable upstream changes: * Index-only scan was included in the batch of upstream commits. It allows queries to retrieve data only from indexes, avoiding heap access. * Group commit was added to work effectively under heavy load. Previously, batching of commits became ineffective as the write workload increased, because of internal lock contention. * A new fast-path lock mechanism was added to reduce the overhead of taking and releasing certain types of locks which are taken and released very frequently but rarely conflict. * The new "parameterized path" mechanism was added. It allows inner index scans to use values from relations that are more than one join level up from the scan. This can greatly improve performance in situations where semantic restrictions (such as outer joins) limit the allowed join orderings. * SP-GiST (Space-Partitioned GiST) index access method was added to support unbalanced partitioned search structures. For suitable problems, SP-GiST can be faster than GiST in both index build time and search time. * Checkpoints now are performed by a dedicated background process. Formerly the background writer did both dirty-page writing and checkpointing. Separating this into two processes allows each goal to be accomplished more predictably. * Custom plan was supported for specific parameter values even when using prepared statements. * API for FDW was improved to provide multiple access "paths" for their tables, allowing more flexibility in join planning. * Security_barrier option was added for views to prevents optimizations that might allow view-protected data to be exposed to users. * Range data type was added to store a lower and upper bound belonging to its base data type. * CTAS (CREATE TABLE AS/SELECT INTO) is now treated as utility statement. The SELECT query is planned during the execution of the utility. To conform to this change, GPDB executes the utility statement only on QD and dispatches the plan of the SELECT query to QEs. Co-authored-by: NAdam Lee <ali@pivotal.io> Co-authored-by: NAlexandra Wang <lewang@pivotal.io> Co-authored-by: NAshwin Agrawal <aagrawal@pivotal.io> Co-authored-by: NAsim R P <apraveen@pivotal.io> Co-authored-by: NDaniel Gustafsson <dgustafsson@pivotal.io> Co-authored-by: NGang Xiong <gxiong@pivotal.io> Co-authored-by: NHaozhou Wang <hawang@pivotal.io> Co-authored-by: NHeikki Linnakangas <hlinnakangas@pivotal.io> Co-authored-by: NJesse Zhang <sbjesse@gmail.com> Co-authored-by: NJinbao Chen <jinchen@pivotal.io> Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io> Co-authored-by: NMelanie Plageman <mplageman@pivotal.io> Co-authored-by: NPaul Guo <paulguo@gmail.com> Co-authored-by: NRichard Guo <guofenglinux@gmail.com> Co-authored-by: NShujie Zhang <shzhang@pivotal.io> Co-authored-by: NTaylor Vesely <tvesely@pivotal.io> Co-authored-by: NZhenghua Lyu <zlv@pivotal.io>
-
- 17 4月, 2018 1 次提交
-
-
由 David Kimura 提交于
Large objects are currently not supported in Greenplum. Rather than deceive the user with a non-functional large object api, we disable them for now. We disable the large object tests in privileges regress test by using ignore blocks instead of commenting them out or deleting them to reduce merge conflicts in future postgres merges. Co-authored-by: NJimmy Yih <jyih@pivotal.io>
-
- 15 2月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
Now that we have merged the upstream changes that introduced the ModifyTable node, it seems like a good time to fix RETURNING. So, here we go.
-
- 23 1月, 2018 1 次提交
-
-
由 Daniel Gustafsson 提交于
Filespaces are no more, remove comment and match schema with upstream.
-
- 13 1月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
This is a backport upstream commit 22817041, from PostgreSQL 9.0, which added the server version number in the path. But in GPDB, also include the gp_dbid in the path. This makes it possible to use the same tablespace path on multiple servers running on the same host, without clashing. Also includes cherry-pick of the small upstream cleanup commits 5c82ccb1 a6f56efc, and c282b36d. Re-enable upstream 'tablespace' regression test. It works now, even when all the nodes are running on same host.
-
- 13 12月, 2017 1 次提交
-
-
由 Shreedhar Hardikar 提交于
The original name was deceptive because this check is also done for QE slices that run on master. For example: EXPLAIN SELECT * FROM func1_nosql_vol(5), foo; QUERY PLAN -------------------------------------------------------------------------------------------- Gather Motion 3:1 (slice2; segments: 3) (cost=0.30..1.37 rows=4 width=12) -> Nested Loop (cost=0.30..1.37 rows=2 width=12) -> Seq Scan on foo (cost=0.00..1.01 rows=1 width=8) -> Materialize (cost=0.30..0.33 rows=1 width=4) -> Broadcast Motion 1:3 (slice1) (cost=0.00..0.30 rows=3 width=4) -> Function Scan on func1_nosql_vol (cost=0.00..0.26 rows=1 width=4) Settings: optimizer=off Optimizer status: legacy query optimizer (8 rows) Note that in the plan, the function func1_nosql_vol() will be executed on a master slice with Gp_role as GP_ROLE_EXECUTE. Also, update output files Signed-off-by: NJesse Zhang <sbjesse@gmail.com>
-
- 24 11月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
This adds some limitations, and removes some functionality that tte old implementation had. These limitations will be lifted, and missing functionality will be added back, in subsequent commits: * You can no longer have variables in start/end offsets * RANGE is not implemented (except for UNBOUNDED) * If you have multiple window functions that require a different sort ordering, the planner is not smart about placing them in a way that minimizes the number of sorts. This also lifts some limitations that the GPDB implementation had: * LEAD/LAG offset can now be negative. In the qp_olap_windowerr, a lot of queries that used to throw an "ROWS parameter cannot be negative" error are now passing. That error was an artifact of the eay LEAD/LAG were implemented. Those queries contain window function calls like "LEAD(col1, col2 - col3)", and sometimes with suitable values in col2 and col3, the second argument went negative. That caused the error. implementation of LEAD/LAG is OK with a negative argument. * Aggregate functions with no prelimfn or invprelimfn are now supported as window functions * Window functions, e.g. rank(), no longer require an ORDER BY. (The output will vary from one invocation to another, though, because the order is then not well defined. This is more annoying on GPDB than on PostgreSQL, because in GDPB the row order tends to vary because the rows are spread out across the cluster and will arrive in the master in unpredictable order) * NTILE doesn't require the argument expression to be in PARTITION BY * A window function's arguments may contain references to an outer query. This changes the OIDs of the built-in window functions to match upstream. Unfortunately, the OIDs had been hard-coded in ORCA, so to work around that until those hard-coded values are fixed in ORCA, the ORCA translator code contains a hack to map the old OID to the new ones.
-
- 12 9月, 2017 1 次提交
-
-
由 Bhuvnesh Chaudhary 提交于
-
- 07 9月, 2017 1 次提交
-
-
由 Haisheng Yuan 提交于
Planner generates plan that doesn't insert any motion between WorkTableScan and its corresponding RecursiveUnion, because currently in GPDB motions are not rescannable. For example, a MPP plan for recursive CTE query may look like: ``` Gather Motion 3:1 -> Recursive Union -> Seq Scan on department Filter: name = 'A'::text -> Nested Loop Join Filter: d.parent_department = sd.id -> WorkTable Scan on subdepartment sd -> Materialize -> Broadcast Motion 3:3 -> Seq Scan on department d ``` For the current solution, the WorkTableScan is always put on the outer side of the top most Join (the recursive part of RecusiveUnion), so that we can safely rescan the inner child of join without worrying about the materialization of a potential underlying motion. This is a heuristic based plan, not a cost based plan. Ideally, the WorkTableScan can be placed on either side of the join with any depth, and the plan should be chosen based on the cost of the recursive plan and the number of recursions. But we will leave it for later work. Note: The hash join is temporarily disabled for plan generation of recursive part, because if the hash table spills, the batch file is going to be removed as it executes. We have a following story to enable spilled hash table to be rescannable. See discussion at gpdb-dev mailing list: https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/s_SoXKlwd6I
-
- 18 7月, 2017 1 次提交
-
-
由 Tom Lane 提交于
It seems pretty confusing to have tests named both largeobject and large_object. The latter is of very recent vintage (commit ff992c07), so get rid of it in favor of merging into the former. Also, enable the LO comment test that was added by commit 70ad7ed4, since the later commit added the then-missing pg_upgrade functionality. The large_object.sql test case is almost completely redundant with that, but not quite: it seems like creating a user-defined LO with an OID in the system range might be an interesting case for pg_upgrade, so let's keep it. Like the earlier patch, back-patch to all supported branches. Discussion: https://postgr.es/m/18665.1500306372@sss.pgh.pa.us
-
- 07 3月, 2017 1 次提交
-
-
由 Stephen Frost 提交于
When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net
-
- 14 2月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
It was not enabled, because there were a lot of errors in it, because of features that have been disabled in Greenplum. Like enforcing foreign keys, INSERT RETURNING, and doing SPI in functions in segments. Those limitations make these tests a less interesting than in the upstream, but there are still many good tests in there too. Like the test for anonymous DO blocks, that are not tested by any other tests. The .sql file was almost identical to the upstream version. Clean it up to be even closer, by re-enabling some commented queries in it, removing the duplicated tests for RETURN QUERY, removing the READS/CONTAINS/MODIFIES SQL DATA noise words etc. Memorize the expected output as it is. That's quite different from the upstream, because of all the disabled functionality, but also because of some cosmetic differences in error messages. The 'schema_topology' test contained a copy of the for_vect(), so remove that, now that we run the real thing.
-
- 14 11月, 2016 1 次提交
-
-
由 Daniel Gustafsson 提交于
During the merge of upstream releases there are FIXME comments added to the codebase for various reasons. Ensure that the FIXME marker is using a single format to make it easier to grep; GPDB_XX_MERGE_FIXME was the most frequently used so settle for that.
-
- 09 11月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
To test, backport test case for CREATE CAST from PostgreSQL 8.4. We don't apparently have any coverage for it previously. The upstream commit for the test case was: commit a1d2e165 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Date: Fri Oct 31 09:17:17 2008 +0000 Add test case for CREATE CAST. Reported by Yandong Yao
-
- 28 10月, 2016 1 次提交
-
-
由 Nikos Armenatzoglou 提交于
Enhancing PGFuncGeneratorInterface, PGIRBuilderFuncGenerator, and PGGenericFuncGenerator with attributes and checks that record and examine if a built-in function is strict or not and generate code accordingly. Authors: Nikos Armenatzoglou, Nikhil Kak, Jimmy Yih, and Karen Huddleston.
-
- 25 8月, 2016 1 次提交
-
-
由 Daniel Gustafsson 提交于
The variadic and default parameters tests are specific to GPDB so move them to our own regress schedule file.
-
- 29 6月, 2016 1 次提交
-
-
由 Robert Haas 提交于
Like the XML data type, we simply store JSON data as text, after checking that it is valid. More complex operations such as canonicalization and comparison may come later, but this is enough for not. There are a few open issues here, such as whether we should attempt to detect UTF-8 surrogate pairs represented as \uXXXX\uYYYY, but this gets the basic framework in place. Author: Álvaro Hernández Tortosa <aht@8kdata.com> Date: Mon Mar 14 17:35:20 UTC 2016 doc/src/sgml/datatype.sgml: changed ignored src/backend/utils/adt/json.c: FIXME: s/errdetail_internal/errdetail/ as errdetail_internal is not supported (yet?) in GPDP. src/backend/commands/explain.c: code from commit 5384a73f was not merged here as ExplainStmt->options is not supported yet in GPDB. Code to be merged: https://github.com/postgres/postgres/commit/5384a73f98d9829725186a7b65bf4f8adb3cfaf1#diff-9ce3cf19c55c48d8714787cf9e3b533f src/include/catalog/pg_type.h: original PostgreSQL's json and _json OIDs where 114 and 199. Since 114 is reserved in GPDB, current assigned OIDs are 3114 and 3199.
-
- 04 6月, 2016 1 次提交
-
-
由 Nikos Armenatzoglou 提交于
Signed-off-by: NGeorge Caragea <gcaragea@pivotal.io>
-
- 26 1月, 2016 1 次提交
-
-
由 Kuien Liu 提交于
Functions can be declared with parameters with default values or expressions. The default expressions are used as parameter value if the parameter is not explicitly specified in a function call. All parameters after a parameter with default value have to be parameters with default values as well. It allows user to invoke a UDF without setting all the parameters. Two examples to demo its usage: CREATE FUNCTION dfunc1(text DEFAULT 'Hello', text DEFAULT 'World') RETURNS text AS $$ SELECT $1 || ', ' || $2; $$ LANGUAGE SQL; SELECT dfunc1(); -- 'Hello, World' SELECT dfunc1('Hi'); -- 'Hi, World' SELECT dfunc1('Hi', 'Beijing'); -- 'Hi, Beijing' CREATE FUNCTION dfunc2(id int4, t timestamp DEFAULT now()) RETURNS text AS $$ SELECT 'Time for id:' || $1 || ' is ' || $2; $$ LANGUAGE SQL; SELECT dfunc2(24); -- 'Time for id:24 is 2016-01-07 14:38' NOTE: The default change set is ported from from PostgreSQL 8.4, original commits: '517ae403' '455dffbb'
-
- 22 12月, 2015 1 次提交
-
-
由 Yu Yang 提交于
User could use VARIADIC to specify parameter list when defining UDF if they want to use variadic parameters. It is easier for user to write only one variadic function instead of same name function with different parameters. An example for using variadic: create function concat(text, variadic anyarray) returns text as $$ select array_to_string($2, $1); $$ language sql immutable strict; select concat('%', 1, 2, 3, 4, 5); NOTE: The variadic change set is ported from upstream of PostgreSQL: commit 517ae403 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Thu Dec 18 18:20:35 2008 +0000 Code review for function default parameters patch. Fix numerous problems as per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch. commit 6563e9e2 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Wed Jul 16 16:55:24 2008 +0000 Add a "provariadic" column to pg_proc to eliminate the remarkably expensive need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column. commit d89737d3 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Wed Jul 16 01:30:23 2008 +0000 Support "variadic" functions, which can accept a variable number of arguments so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Conflicts: src/backend/gpopt/gpdbwrappers.cpp
-
- 20 12月, 2015 1 次提交
-
-
由 Robert Mu 提交于
Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to fix this commit b64d92f1 Author: Andres Freund <andres@anarazel.de> Date: Thu Sep 25 23:49:05 2014 +0200 Add a basic atomic ops API abstracting away platform/architecture details. Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
-
- 03 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
Remove unnecessary ORDER BY clauses that are not present in the upstream version. Disable COPY BINARY test, as GPDB doesn't support BINARY copy. Finally, adjust the error messages in the expected output to match what you get nowadays. DROP TABLE cleanup commands have been added to some other tests, so that the extra user tables don't appear in the output of the 'misc' test. It's not very nice of the 'misc' test to list all user tables, but this nevertheless seems less likely to cause merge conflicts than ripping out that part of the test altogether. There are still differences in the list of user tables though.
-
- 02 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
Revert some unnecessary changes compared to upstream: there's no need for ORDER BYs in queries, gpdiff.pl will mask out row order differences. That needed some fixes to atmsort.pl though, to make it smarter about reordering COPY TO STDOUT results. It used to only deal with the COPY (SELECT ...) TO STDOUT variant, and particularly named tables (COPY .*test1 TO STDOUT). Make it handle all COPY TO STDOUT commands. Also make it smarter about detecting the end of COPY TO STDOUT output. In addition to -- or ERROR, also treat any SELECT, UPDATE, CREATE etc. command as the end of result. In the passing, remove the "-- copy_stdout" command from atmsort.pl, as it was unused. No need to label the functions as immutable or with NO SQL or MODIFIES SQL DATA, and update the error message in the expected output about cross-segment access within functions. One of the tests gives a different error than on upstream: an empty line gives "invalid integer" error in upstream, but "missing data" on GPDB. I'm not quite sure what's causing that, but both errors seem reasonable for that case (the "missing data" is perhaps even better), so let's just memorize that difference.
-
- 28 10月, 2015 1 次提交
-
-
- 08 10月, 2015 1 次提交
-
-
由 Andrew Dunstan 提交于
This lets us remove the large alternative results files for the main json and jsonb tests, which makes modifying those tests simpler for committers and patch submitters. Backpatch to 9.4 for jsonb and 9.3 for json.
-
- 02 10月, 2014 1 次提交
-
-
由 Tom Lane 提交于
As of commit a87c7291 (which later got backpatched as far as 9.1), we're explicitly supporting the notion that append relations can be nested; this can occur when UNION ALL constructs are nested, or when a UNION ALL contains a table with inheritance children. Bug #11457 from Nelson Page, as well as an earlier report from Elvis Pranskevichus, showed that there were still nasty bugs associated with such cases: in particular the EquivalenceClass mechanism could try to generate "join" clauses connecting an appendrel child to some grandparent appendrel, which would result in assertion failures or bogus plans. Upon investigation I concluded that all current callers of find_childrel_appendrelinfo() need to be fixed to explicitly consider multiple levels of parent appendrels. The most complex fix was in processing of "broken" EquivalenceClasses, which are ECs for which we have been unable to generate all the derived equality clauses we would like to because of missing cross-type equality operators in the underlying btree operator family. That code path is more or less entirely untested by the regression tests to date, because no standard opfamilies have such holes in them. So I wrote a new regression test script to try to exercise it a bit, which turned out to be quite a worthwhile activity as it exposed existing bugs in all supported branches. The present patch is essentially the same as far back as 9.2, which is where parameterized paths were introduced. In 9.0 and 9.1, we only need to back-patch a small fragment of commit 5b7b5518, which fixes failure to propagate out the original WHERE clauses when a broken EC contains constant members. (The regression test case results show that these older branches are noticeably stupider than 9.2+ in terms of the quality of the plans generated; but we don't really care about plan quality in such cases, only that the plan not be outright wrong. A more invasive fix in the older branches would not be a good idea anyway from a plan-stability standpoint.)
-
- 08 4月, 2014 1 次提交
-
-
由 Robert Haas 提交于
These functions won't throw an error if the object doesn't exist, or if (for functions and operators) there's more than one matching object. Yugo Nagata and Nozomi Anzai, reviewed by Amit Khandekar, Marti Raudsepp, Amit Kapila, and me.
-