- 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
-
- 02 12月, 2015 1 次提交
-
-
由 Gang Xiong 提交于
Alter partitioned table set distributed by will dispatch information from QD to QEs, the information is not correctly coded and decoded on both sides when: 1. reorganize = false. 2. table have index. 3. partition table have "with" option.
-
- 18 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
It was just syntax and catalogs, you couldn't actually do anything useful with it. Remove it, so that we have less code to maintain, until it's time to merge this stuff from upstream again when we merge with PostgreSQL 8.4. It's probably easier to merge this back at that point than maintain this backported version in the meanwhile. Less effort now, until we reach that point, and once we get to the point in 8.4 that we merge this in, we'll have all the preceding patches applied already, so it should merge quite smoothly.
-
- 13 11月, 2015 2 次提交
-
-
由 Heikki Linnakangas 提交于
Currently, readfast.c / outfast.c are mostly copy-pasted from readfuncs.c / outfuncs.c. That's a merge hazard: if a new field is added to a struct in upstream, and it's added to readfuncs.c and outfuncs.c, we would need to manually do the same in the readfast.c/outfast.c. If the patch applies cleanly, we will not notice, and we'll have a bug of omission. Refactor the code so that all those node types where the text and binary functions are identical, the duplicate in [read/out]fast.c is removed, and the definition [read/out]funcs.c is used to compile the binary version too. This involves some tricks with #ifdefs and #includes, but cuts a lot of duplicate code. This should avoid the merge hazard. We'll still need to maintain the read/out functions whenever we modify a struct in Greenplum, but that's no different from what needs to be done in PostgreSQL.
-
由 Heikki Linnakangas 提交于
This reduces the diff between readfast.c and readfuncs.c. There are of course parts of these files that need to be different, but the bulk of the functions should be identical, with all the differences hidden in the READ_* macros. This patch reduces the diff and thus makes any suspicious differences between them more obvious.
-
- 28 10月, 2015 1 次提交
-
-