- 30 May, 2010 1 commit
-
-
Tom Lane authored
"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.
-
- 03 Nov, 2009 1 commit
-
-
Peter Eisentraut authored
-
- 08 Oct, 2009 1 commit
-
-
Tom Lane authored
match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule
-
- 09 Feb, 2009 1 commit
-
-
Tom Lane authored
contents of hash indexes (again), so bump catversion. Kenneth Marshall
-
- 18 Dec, 2008 1 commit
-
-
Tom Lane authored
per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
-
- 14 Dec, 2008 1 commit
-
-
Tom Lane authored
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.
-
- 04 Dec, 2008 1 commit
-
-
Peter Eisentraut authored
Pavel Stehule, with some tweaks by Peter Eisentraut
-
- 03 Nov, 2008 1 commit
-
-
Tom Lane authored
Brendan Jurd
-
- 16 Jul, 2008 1 commit
-
-
Tom Lane authored
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
-
- 11 Jan, 2008 1 commit
-
-
Tom Lane authored
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.
-
- 01 May, 2007 1 commit
-
-
Tom Lane authored
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.
-
- 27 Jul, 2006 1 commit
-
-
Tom Lane authored
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.
-
- 27 Feb, 2006 1 commit
-
-
Peter Eisentraut authored
particular get rid of single quotes around language names and old WITH () construct.
-
- 01 Jul, 2003 1 commit
-
-
Tom Lane authored
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.
-