summaryrefslogtreecommitdiff
path: root/src/test/regress/sql/polymorphism.sql
Commit message (Collapse)AuthorAgeFilesLines
* Fix getTypeIOParam to support type record[].Tom Lane2011-12-011-0/+15
| | | | | | | | | | | | | Since record[] uses array_in, it needs to have its element type passed as typioparam. In HEAD and 9.1, this fix essentially reverts commit 9bc933b2125a5358722490acbc50889887bf7680, which was a hack that is no longer needed since domains don't set their typelem anymore. Before that, adjust the logic so that only domains are excluded from being treated like arrays, rather than assuming that only base types should be included. Add a regression test to demonstrate the need for this. Per report from Maxim Boguk. Back-patch to 8.4, where type record[] was added.
* Adjust regression test to avoid platform-dependent failure.Tom Lane2011-03-141-1/+2
| | | | | | | | | We have a test that verifies that max(anyarray) will cope if the array column elements aren't all the same array type. However, it's now possible for that to produce a collation-related error message instead of the expected one, if the first two column elements happen to be of the same type and it's one that expects to be given collation info. Tweak the test to ensure this doesn't happen. Per buildfarm member pika.
* Change the notation for calling functions with named parameters fromTom Lane2010-05-301-29/+29
| | | | | | | | | | | | | "val AS name" to "name := val", as per recent discussion. This patch catches everything in the original named-parameters patch, but I'm not certain that no other dependencies snuck in later (grepping the source tree for all uses of AS soon proved unworkable). In passing I note that we've dropped the ball at least once on keeping ecpg's lexer (as opposed to parser) in sync with the backend. It would be a good idea to go through all of pgc.l and see if it's in sync now. I didn't attempt that at the moment.
* Fix regression tests for psql \d view patchPeter Eisentraut2009-11-031-1/+1
|
* Support use of function argument names to identify which actual argumentsTom Lane2009-10-081-2/+123
| | | | | | | match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule
* Adopt Bob Jenkins' improved hash function for hash_any(). This changes theTom Lane2009-02-091-23/+23
| | | | | | contents of hash indexes (again), so bump catversion. Kenneth Marshall
* Code review for function default parameters patch. Fix numerous problems asTom Lane2008-12-181-26/+49
| | | | | per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
* Restore enforce_generic_type_consistency's pre-8.3 behavior of allowing anTom Lane2008-12-141-0/+7
| | | | | | | actual argument type of ANYARRAY to match an argument declared ANYARRAY, so long as ANYELEMENT etc aren't used. I had overlooked the fact that this is a possible case while fixing bug #3852; but it is possible because pg_statistic contains columns declared ANYARRAY. Per gripe from Corey Horton.
* Default values for function argumentsPeter Eisentraut2008-12-041-0/+114
| | | | Pavel Stehule, with some tweaks by Peter Eisentraut
* Add pg_typeof() function.Tom Lane2008-11-031-0/+11
| | | | Brendan Jurd
* Support "variadic" functions, which can accept a variable number of argumentsTom Lane2008-07-161-0/+43
| | | | | | | | | | | | | | 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. Pavel Stehule
* The original implementation of polymorphic aggregates didn't really get theTom Lane2008-01-111-0/+36
| | | | | | checking of argument compatibility right; although the problem is only exposed with multiple-input aggregates in which some arguments are polymorphic and some are not. Per bug #3852 from Sokolov Yura.
* Fix a thinko in my patch of a couple months ago for bug #3116: it did theTom Lane2007-05-011-0/+16
| | | | | | | | | | wrong thing when inlining polymorphic SQL functions, because it was using the function's declared return type where it should have used the actual result type of the current call. In 8.1 and 8.2 this causes obvious failures even if you don't have assertions turned on; in 8.0 and 7.4 it would only be a problem if the inlined expression were used as an input to a function that did run-time type determination on its inputs. Add a regression test, since this is evidently an under-tested area.
* Aggregate functions now support multiple input arguments. I also tookTom Lane2006-07-271-12/+21
| | | | | | | | the opportunity to treat COUNT(*) as a zero-argument aggregate instead of the old hack that equated it to COUNT(1); this is materially cleaner (no more weird ANYOID cases) and ought to be at least a tiny bit faster. Original patch by Sergey Koposov; review, documentation, simple regression tests, pg_dump and psql support by moi.
* Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, inPeter Eisentraut2006-02-271-15/+15
| | | | | particular get rid of single quotes around language names and old WITH () construct.
* Aggregates can be polymorphic, using polymorphic implementation functions.Tom Lane2003-07-011-0/+367
It also works to create a non-polymorphic aggregate from polymorphic functions, should you want to do that. Regression test added, docs still lacking. By Joe Conway, with some kibitzing from Tom Lane.
View Lorry Controller Status