postgres

Commit Graph

Author	SHA1	Message	Date
Robert Haas	865f14a2d3	Allow named parameters to be specified using => in addition to := SQL has standardized on => as the use of to specify named parameters, and we've wanted for many years to support the same syntax ourselves, but this has been complicated by the possible use of => as an operator name. In PostgreSQL 9.0, we began emitting a warning when an operator named => was defined, and in PostgreSQL 9.2, we stopped shipping a =>(text, text) operator as part of hstore. By the time the next major version of PostgreSQL is released, => will have been deprecated for a full five years, so hopefully there won't be too many people still relying on it. We continue to support := for compatibility with previous PostgreSQL releases. Pavel Stehule, reviewed by Petr Jelinek, with a few documentation tweaks by me.	11 years ago
Tom Lane	65d9aedb1b	Fix getTypeIOParam to support type record[]. 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 `9bc933b212`, 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.	14 years ago
Tom Lane	f12423d75a	Adjust regression test to avoid platform-dependent failure. 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.	15 years ago
Tom Lane	b12b7a9038	Change the notation for calling functions with named parameters from "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.	16 years ago
Peter Eisentraut	16cd34a435	Fix regression tests for psql \d view patch	16 years ago
Tom Lane	717fa274d1	Support use of function argument names to identify which actual arguments match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule	17 years ago
Tom Lane	8205258fa6	Adopt Bob Jenkins' improved hash function for hash_any(). This changes the contents of hash indexes (again), so bump catversion. Kenneth Marshall	17 years ago
Tom Lane	517ae4039e	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.	17 years ago
Tom Lane	a9d5f30be3	Restore enforce_generic_type_consistency's pre-8.3 behavior of allowing an 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.	17 years ago
Peter Eisentraut	455dffbb73	Default values for function arguments Pavel Stehule, with some tweaks by Peter Eisentraut	17 years ago
Tom Lane	b8fab2411d	Add pg_typeof() function. Brendan Jurd	17 years ago
Tom Lane	d89737d31c	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. Pavel Stehule	18 years ago
Tom Lane	89c0a87fda	The original implementation of polymorphic aggregates didn't really get the 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.	18 years ago
Tom Lane	b4349519c1	Fix a thinko in my patch of a couple months ago for bug #3116 : it did the 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.	19 years ago
Tom Lane	108fe47301	Aggregate functions now support multiple input arguments. I also took 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.	20 years ago
Peter Eisentraut	7f4f42fa10	Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.	20 years ago
Tom Lane	e3b1b6c0cd	Aggregates can be polymorphic, using polymorphic implementation functions. 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.	23 years ago

17 Commits (e95126cf048b08d7ff5eb72ec33737e9e27c08f8)