22 Commits (a9c35cf85ca1ff72f16f0f10d7ddee6e582b62b8)

Author	SHA1	Message	Date
Andres Freund	a9c35cf85c	Change function call information to be variable length. ... Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de	7 years ago
Andres Freund	5ded4bd214	Remove support for version-0 calling conventions. ... The V0 convention is failure prone because we've so far assumed that a function is V0 if PG_FUNCTION_INFO_V1 is missing, leading to crashes if a function was coded against the V1 interface. V0 doesn't allow proper NULL, SRF and toast handling. V0 doesn't offer features that V1 doesn't. Thus remove V0 support and obsolete fmgr README contents relating to it. Author: Andres Freund, with contributions by Peter Eisentraut & Craig Ringer Reviewed-By: Peter Eisentraut, Craig Ringer Discussion: https://postgr.es/m/20161208213441.k3mbno4twhg2qf7g@alap3.anarazel.de	9 years ago
Tom Lane	d26b042ce5	Fix documentation of FmgrInfo.fn_nargs. ... Some ancient comments claimed that fn_nargs could be -1 to indicate a variable number of input arguments; but this was never implemented, and is at variance with what we ultimately did with "variadic" functions. Update the comments.	12 years ago
Tom Lane	d64713df7e	Pass collations to functions in FunctionCallInfoData, not FmgrInfo. ... Since collation is effectively an argument, not a property of the function, FmgrInfo is really the wrong place for it; and this becomes critical in cases where a cached FmgrInfo is used for varying purposes that might need different collation settings. Fix by passing it in FunctionCallInfoData instead. In particular this allows a clean fix for bug #5970 (record_cmp not working). This requires touching a bit more code than the original method, but nobody ever thought that collations would not be an invasive patch...	15 years ago
Tom Lane	b310b6e31c	Revise collation derivation method and expression-tree representation. ... All expression nodes now have an explicit output-collation field, unless they are known to only return a noncollatable data type (such as boolean or record). Also, nodes that can invoke collation-aware functions store a separate field that is the collation value to pass to the function. This avoids confusion that arises when a function has collatable inputs and noncollatable output type, or vice versa. Also, replace the parser's on-the-fly collation assignment method with a post-pass over the completed expression tree. This allows us to use a more complex (and hopefully more nearly spec-compliant) assignment rule without paying for it in extra storage in every expression node. Fix assorted bugs in the planner's handling of collations by making collation one of the defining properties of an EquivalenceClass and by converting CollateExprs into discardable RelabelType nodes during expression preprocessing.	15 years ago
Magnus Hagander	9f2e211386	Remove cvs keywords from all files.	15 years ago
Tom Lane	9b46abb7c4	Allow SQL-language functions to return the output of an INSERT/UPDATE/DELETE ... RETURNING clause, not just a SELECT as formerly. A side effect of this patch is that when a set-returning SQL function is used in a FROM clause, performance is improved because the output is collected into a tuplestore within the function, rather than using the less efficient value-per-call mechanism.	17 years ago
Tom Lane	05bba3d176	Be more tense about not creating tuplestores with randomAccess = true unless ... backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.	17 years ago
Tom Lane	e3e3d2a789	Extend ExecMakeFunctionResult() to support set-returning functions that return ... via a tuplestore instead of value-per-call. Refactor a few things to reduce ensuing code duplication with nodeFunctionscan.c. This represents the reasonably noncontroversial part of my proposed patch to switch SQL functions over to returning tuplestores. For the moment, SQL functions still do things the old way. However, this change enables PL SRFs to be called in targetlists (observe changes in plperl regression results).	17 years ago
Tom Lane	93c701edc6	Add support for tracking call counts and elapsed runtime for user-defined ... functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)	18 years ago
Tom Lane	8472bf7a73	Allow float8, int8, and related datatypes to be passed by value on machines ... where Datum is 8 bytes wide. Since this will break old-style C functions (those still using version 0 calling convention) that have arguments or results of these types, provide a configure option to disable it and retain the old pass-by-reference behavior. Likewise, provide a configure option to disable the recently-committed float4 pass-by-value change. Zoltan Boszormenyi, plus configurability stuff by me.	18 years ago
Alvaro Herrera	7861d72ea2	Modify the float4 datatype to be pass-by-val. Along the way, remove the last ... uses of the long-deprecated float32 in contrib/seg; the definitions themselves are still there, but no longer used. fmgr/README updated to match. I added a CREATE FUNCTION to account for existing seg_center() code in seg.c too, and some tests for it and the neighbor functions. At the same time, remove checks for NULL which are not needed (because the functions are declared STRICT). I had to do some adjustments to contrib's btree_gist too. The choices for representation there are not ideal for changing the underlying types :-( Original patch by Zoltan Boszormenyi, with some adjustments by me.	18 years ago
Bruce Momjian	4e228447aa	Make source code READMEs more consistent. Add CVS tags to all README files.	18 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	689eb53e47	Error message editing in backend/utils (except /adt).	22 years ago
Tom Lane	730840c9b6	First phase of work on array improvements. ARRAY[x,y,z] constructor ... expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.	23 years ago
Tom Lane	7bacf2befa	Add expected tuple descriptor to ReturnSetInfo information for table ... functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.	23 years ago
Tom Lane	e107f3a7e3	PL/pgSQL functions can return sets. Neil Conway's patch, modified so ... that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.	23 years ago
Tom Lane	f9e4f611a1	First pass at set-returning-functions in FROM, by Joe Conway with ... some kibitzing from Tom Lane. Not everything works yet, and there's no documentation or regression test, but let's commit this so Joe doesn't need to cope with tracking changes in so many files ...	24 years ago
Tom Lane	3e09584fd3	Fix typo.	25 years ago
Tom Lane	959851272d	Update README with proposed new method for determining calling convention ... of user-defined functions (forget 'C' vs 'newC', instead require an info function to be present for new-style functions). Also update some other out-of-date commentary.	25 years ago
Tom Lane	305d3ce576	Install fmgr rewrite doc as README file. ... Need to update user docs still ...	26 years ago