1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* fastpath.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* routines to handle function requests from the frontend
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2001-01-24 20:43:33 +01:00
|
|
|
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2001-06-01 17:45:42 +02:00
|
|
|
* $Header: /cvsroot/pgsql/src/backend/tcop/fastpath.c,v 1.49 2001/06/01 15:45:42 tgl Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
1997-09-07 07:04:48 +02:00
|
|
|
* This cruft is the server side of PQfn.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* - jolly 07/11/95:
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* no longer rely on return sizes provided by the frontend. Always
|
|
|
|
* use the true lengths for the catalogs. Assume that the frontend
|
|
|
|
* has allocated enough space to handle the result value returned.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* trust that the user knows what he is doing with the args. If the
|
|
|
|
* sys catalog says it is a varlena, assume that the user is only sending
|
|
|
|
* down VARDATA and that the argsize is the VARSIZE. If the arg is
|
|
|
|
* fixed len, assume that the argsize given by the user is correct.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* if the function returns by value, then only send 4 bytes value
|
|
|
|
* back to the frontend. If the return returns by reference,
|
|
|
|
* send down only the data portion and set the return size appropriately.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* OLD COMMENTS FOLLOW
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* The VAR_LENGTH_{ARGS,RESULT} stuff is limited to MAX_STRING_LENGTH
|
|
|
|
* (see src/backend/tmp/fastpath.h) for no obvious reason. Since its
|
|
|
|
* primary use (for us) is for Inversion path names, it should probably
|
|
|
|
* be increased to 256 (MAXPATHLEN for Inversion, hidden in pg_type
|
|
|
|
* as well as utils/adt/filename.c).
|
|
|
|
*
|
|
|
|
* Quoth PMA on 08/15/93:
|
|
|
|
*
|
|
|
|
* This code has been almost completely rewritten with an eye to
|
|
|
|
* keeping it as compatible as possible with the previous (broken)
|
|
|
|
* implementation.
|
|
|
|
*
|
|
|
|
* The previous implementation would assume (1) that any value of
|
|
|
|
* length <= 4 bytes was passed-by-value, and that any other value
|
|
|
|
* was a struct varlena (by-reference). There was NO way to pass a
|
1998-04-26 06:12:15 +02:00
|
|
|
* fixed-length by-reference argument (like name) or a struct
|
1997-09-07 07:04:48 +02:00
|
|
|
* varlena of size <= 4 bytes.
|
|
|
|
*
|
|
|
|
* The new implementation checks the catalogs to determine whether
|
|
|
|
* a value is by-value (type "0" is null-delimited character string,
|
|
|
|
* as it is for, e.g., the parser). The only other item obtained
|
|
|
|
* from the catalogs is whether or not the value should be placed in
|
|
|
|
* a struct varlena or not. Otherwise, the size given by the
|
|
|
|
* frontend is assumed to be correct (probably a bad decision, but
|
|
|
|
* we do strange things in the name of compatibility).
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
1999-07-16 05:14:30 +02:00
|
|
|
#include "access/xact.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "catalog/pg_proc.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "libpq/libpq.h"
|
|
|
|
#include "libpq/pqformat.h"
|
|
|
|
#include "tcop/fastpath.h"
|
2001-06-01 17:45:42 +02:00
|
|
|
#include "utils/lsyscache.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "utils/syscache.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* SendFunctionResult
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
static void
|
2001-03-22 05:01:46 +01:00
|
|
|
SendFunctionResult(Datum retval,/* actual return value */
|
1997-09-07 07:04:48 +02:00
|
|
|
bool retbyval,
|
2000-05-28 19:56:29 +02:00
|
|
|
int retlen) /* the length according to the catalogs */
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1999-04-25 05:19:27 +02:00
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_beginmessage(&buf);
|
|
|
|
pq_sendbyte(&buf, 'V');
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (retlen != 0)
|
|
|
|
{
|
1999-04-25 05:19:27 +02:00
|
|
|
pq_sendbyte(&buf, 'G');
|
1997-09-07 07:04:48 +02:00
|
|
|
if (retbyval)
|
|
|
|
{ /* by-value */
|
1999-04-25 05:19:27 +02:00
|
|
|
pq_sendint(&buf, retlen, 4);
|
2000-05-28 19:56:29 +02:00
|
|
|
pq_sendint(&buf, DatumGetInt32(retval), retlen);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* by-reference ... */
|
|
|
|
if (retlen < 0)
|
|
|
|
{ /* ... varlena */
|
2000-05-28 19:56:29 +02:00
|
|
|
struct varlena *v = (struct varlena *) DatumGetPointer(retval);
|
|
|
|
|
|
|
|
pq_sendint(&buf, VARSIZE(v) - VARHDRSZ, VARHDRSZ);
|
|
|
|
pq_sendbytes(&buf, VARDATA(v), VARSIZE(v) - VARHDRSZ);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* ... fixed */
|
1999-04-25 05:19:27 +02:00
|
|
|
pq_sendint(&buf, retlen, 4);
|
2000-05-28 19:56:29 +02:00
|
|
|
pq_sendbytes(&buf, DatumGetPointer(retval), retlen);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1999-04-25 05:19:27 +02:00
|
|
|
pq_sendbyte(&buf, '0');
|
|
|
|
pq_endmessage(&buf);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-01 17:45:42 +02:00
|
|
|
* Formerly, this code attempted to cache the function and type info
|
|
|
|
* looked up by fetch_fp_info, but only for the duration of a single
|
|
|
|
* transaction command (since in theory the info could change between
|
|
|
|
* commands). This was utterly useless, because postgres.c executes
|
|
|
|
* each fastpath call as a separate transaction command, and so the
|
|
|
|
* cached data could never actually have been reused. If it had worked
|
|
|
|
* as intended, it would have had problems anyway with dangling references
|
|
|
|
* in the FmgrInfo struct. So, forget about caching and just repeat the
|
|
|
|
* syscache fetches on each usage. They're not *that* expensive.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
struct fp_info
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Oid funcid;
|
2000-05-28 19:56:29 +02:00
|
|
|
FmgrInfo flinfo; /* function lookup info for funcid */
|
2001-06-01 17:45:42 +02:00
|
|
|
int16 arglen[FUNC_MAX_ARGS];
|
2000-01-10 18:14:46 +01:00
|
|
|
bool argbyval[FUNC_MAX_ARGS];
|
2001-06-01 17:45:42 +02:00
|
|
|
int16 retlen;
|
1997-09-08 04:41:22 +02:00
|
|
|
bool retbyval;
|
1996-07-09 08:22:35 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2001-06-01 17:45:42 +02:00
|
|
|
* fetch_fp_info
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* Performs catalog lookups to load a struct fp_info 'fip' for the
|
|
|
|
* function 'func_id'.
|
|
|
|
*/
|
|
|
|
static void
|
2001-06-01 17:45:42 +02:00
|
|
|
fetch_fp_info(Oid func_id, struct fp_info * fip)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-01-10 17:13:23 +01:00
|
|
|
Oid *argtypes; /* an oidvector */
|
1997-09-08 04:41:22 +02:00
|
|
|
Oid rettype;
|
2001-06-01 17:45:42 +02:00
|
|
|
HeapTuple func_htp;
|
1997-09-08 04:41:22 +02:00
|
|
|
Form_pg_proc pp;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
Assert(OidIsValid(func_id));
|
|
|
|
Assert(fip != (struct fp_info *) NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since the validity of this structure is determined by whether the
|
|
|
|
* funcid is OK, we clear the funcid here. It must not be set to the
|
|
|
|
* correct value until we are about to return with a good struct
|
1998-01-07 22:07:04 +01:00
|
|
|
* fp_info, since we can be interrupted (i.e., with an elog(ERROR,
|
2001-06-01 17:45:42 +02:00
|
|
|
* ...)) at any time. [No longer really an issue since we don't save
|
|
|
|
* the struct fp_info across transactions anymore, but keep it anyway.]
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-06-01 17:45:42 +02:00
|
|
|
MemSet((char *) fip, 0, sizeof(struct fp_info));
|
1997-09-07 07:04:48 +02:00
|
|
|
fip->funcid = InvalidOid;
|
|
|
|
|
2001-06-01 17:45:42 +02:00
|
|
|
fmgr_info(func_id, &fip->flinfo);
|
|
|
|
|
2000-11-16 23:30:52 +01:00
|
|
|
func_htp = SearchSysCache(PROCOID,
|
|
|
|
ObjectIdGetDatum(func_id),
|
|
|
|
0, 0, 0);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!HeapTupleIsValid(func_htp))
|
2001-06-01 17:45:42 +02:00
|
|
|
elog(ERROR, "fetch_fp_info: cache lookup for function %u failed",
|
1997-09-07 07:04:48 +02:00
|
|
|
func_id);
|
|
|
|
pp = (Form_pg_proc) GETSTRUCT(func_htp);
|
|
|
|
rettype = pp->prorettype;
|
|
|
|
argtypes = pp->proargtypes;
|
|
|
|
|
2001-06-01 17:45:42 +02:00
|
|
|
for (i = 0; i < pp->pronargs; ++i)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
if (OidIsValid(argtypes[i]))
|
2001-06-01 17:45:42 +02:00
|
|
|
get_typlenbyval(argtypes[i], &fip->arglen[i], &fip->argbyval[i]);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (OidIsValid(rettype))
|
2001-06-01 17:45:42 +02:00
|
|
|
get_typlenbyval(rettype, &fip->retlen, &fip->retbyval);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-11-16 23:30:52 +01:00
|
|
|
ReleaseSysCache(func_htp);
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
|
|
|
* This must be last!
|
|
|
|
*/
|
|
|
|
fip->funcid = func_id;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* HandleFunctionRequest
|
|
|
|
*
|
|
|
|
* Server side of PQfn (fastpath function calls from the frontend).
|
|
|
|
* This corresponds to the libpq protocol symbol "F".
|
|
|
|
*
|
|
|
|
* RETURNS:
|
1999-07-22 04:40:07 +02:00
|
|
|
* 0 if successful completion, EOF if frontend connection lost.
|
|
|
|
*
|
|
|
|
* Note: All ordinary errors result in elog(ERROR,...). However,
|
|
|
|
* if we lose the frontend connection there is no one to elog to,
|
|
|
|
* and no use in proceeding...
|
2000-10-24 22:59:35 +02:00
|
|
|
*
|
|
|
|
* Note: palloc()s done here and in the called function do not need to be
|
|
|
|
* cleaned up explicitly. We are called from PostgresMain() in the
|
|
|
|
* QueryContext memory context, which will be automatically reset when
|
|
|
|
* control returns to PostgresMain.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
int
|
2000-10-24 22:59:35 +02:00
|
|
|
HandleFunctionRequest(void)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Oid fid;
|
|
|
|
int argsize;
|
|
|
|
int nargs;
|
1999-04-25 05:19:27 +02:00
|
|
|
int tmp;
|
2000-05-28 19:56:29 +02:00
|
|
|
FunctionCallInfoData fcinfo;
|
|
|
|
Datum retval;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
char *p;
|
2001-06-01 17:45:42 +02:00
|
|
|
struct fp_info my_fp;
|
1997-09-07 07:04:48 +02:00
|
|
|
struct fp_info *fip;
|
|
|
|
|
2000-10-24 22:59:35 +02:00
|
|
|
/*
|
|
|
|
* XXX FIXME: This protocol is misdesigned.
|
|
|
|
*
|
|
|
|
* We really do not want to elog() before having swallowed all of the
|
2001-03-22 05:01:46 +01:00
|
|
|
* frontend's fastpath message; otherwise we will lose sync with the
|
|
|
|
* input datastream. What should happen is we absorb all of the input
|
|
|
|
* message per protocol syntax, and *then* do error checking
|
|
|
|
* (including lookup of the given function ID) and elog if
|
|
|
|
* appropriate. Unfortunately, because we cannot even read the
|
|
|
|
* message properly without knowing whether the data types are
|
2001-03-22 07:16:21 +01:00
|
|
|
* pass-by-ref or pass-by-value, it's not all that easy to do :-(. The
|
|
|
|
* protocol should require the client to supply what it thinks is the
|
|
|
|
* typbyval and typlen value for each arg, so that we can read the
|
2001-03-22 05:01:46 +01:00
|
|
|
* data without having to do any lookups. Then after we've read the
|
|
|
|
* message, we should do the lookups, verify agreement of the actual
|
|
|
|
* function arg types with what we received, and finally call the
|
|
|
|
* function.
|
2000-10-24 22:59:35 +02:00
|
|
|
*
|
|
|
|
* As things stand, not only will we lose sync for an invalid message
|
2001-03-22 05:01:46 +01:00
|
|
|
* (such as requested function OID doesn't exist), but we may lose
|
|
|
|
* sync for a perfectly valid message if we are in transaction-aborted
|
|
|
|
* state! This can happen because our database lookup attempts may
|
|
|
|
* fail entirely in abort state.
|
2000-10-24 22:59:35 +02:00
|
|
|
*
|
|
|
|
* Unfortunately I see no way to fix this without breaking a lot of
|
2001-03-22 05:01:46 +01:00
|
|
|
* existing clients. Maybe do it as part of next protocol version
|
|
|
|
* change.
|
2000-10-24 22:59:35 +02:00
|
|
|
*/
|
|
|
|
|
1999-07-22 04:40:07 +02:00
|
|
|
if (pq_getint(&tmp, 4)) /* function oid */
|
|
|
|
return EOF;
|
1999-04-25 05:19:27 +02:00
|
|
|
fid = (Oid) tmp;
|
1999-07-22 04:40:07 +02:00
|
|
|
if (pq_getint(&nargs, 4)) /* # of arguments */
|
|
|
|
return EOF;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2001-06-01 17:45:42 +02:00
|
|
|
* There used to be a lame attempt at caching lookup info here.
|
|
|
|
* Now we just do the lookups on every call.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-06-01 17:45:42 +02:00
|
|
|
fip = &my_fp;
|
|
|
|
fetch_fp_info(fid, fip);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
if (fip->flinfo.fn_nargs != nargs || nargs > FUNC_MAX_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1998-01-07 22:07:04 +01:00
|
|
|
elog(ERROR, "HandleFunctionRequest: actual arguments (%d) != registered arguments (%d)",
|
2000-05-28 19:56:29 +02:00
|
|
|
nargs, fip->flinfo.fn_nargs);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
MemSet(&fcinfo, 0, sizeof(fcinfo));
|
|
|
|
fcinfo.flinfo = &fip->flinfo;
|
|
|
|
fcinfo.nargs = nargs;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2000-05-28 19:56:29 +02:00
|
|
|
* Copy supplied arguments into arg vector. Note there is no way for
|
|
|
|
* frontend to specify a NULL argument --- more misdesign.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-05-28 19:56:29 +02:00
|
|
|
for (i = 0; i < nargs; ++i)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-05-28 19:56:29 +02:00
|
|
|
if (pq_getint(&argsize, 4))
|
|
|
|
return EOF;
|
|
|
|
if (fip->argbyval[i])
|
|
|
|
{ /* by-value */
|
|
|
|
if (argsize < 1 || argsize > 4)
|
|
|
|
elog(ERROR, "HandleFunctionRequest: bogus argsize %d",
|
|
|
|
argsize);
|
|
|
|
/* XXX should we demand argsize == fip->arglen[i] ? */
|
|
|
|
if (pq_getint(&tmp, argsize))
|
1999-07-22 04:40:07 +02:00
|
|
|
return EOF;
|
2000-05-28 19:56:29 +02:00
|
|
|
fcinfo.arg[i] = (Datum) tmp;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* by-reference ... */
|
|
|
|
if (fip->arglen[i] < 0)
|
|
|
|
{ /* ... varlena */
|
|
|
|
if (argsize < 0)
|
|
|
|
elog(ERROR, "HandleFunctionRequest: bogus argsize %d",
|
|
|
|
argsize);
|
|
|
|
/* I suspect this +1 isn't really needed - tgl 5/2000 */
|
2001-03-22 05:01:46 +01:00
|
|
|
p = palloc(argsize + VARHDRSZ + 1); /* Added +1 to solve
|
|
|
|
* memory leak - Peter
|
|
|
|
* 98 Jan 6 */
|
2000-07-04 01:10:14 +02:00
|
|
|
VARATT_SIZEP(p) = argsize + VARHDRSZ;
|
2000-05-28 19:56:29 +02:00
|
|
|
if (pq_getbytes(VARDATA(p), argsize))
|
1999-07-22 04:40:07 +02:00
|
|
|
return EOF;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2000-05-28 19:56:29 +02:00
|
|
|
{ /* ... fixed */
|
|
|
|
if (argsize != fip->arglen[i])
|
|
|
|
elog(ERROR, "HandleFunctionRequest: bogus argsize %d, should be %d",
|
|
|
|
argsize, fip->arglen[i]);
|
2001-03-22 05:01:46 +01:00
|
|
|
p = palloc(argsize + 1); /* +1 in case argsize is 0 */
|
2000-05-28 19:56:29 +02:00
|
|
|
if (pq_getbytes(p, argsize))
|
|
|
|
return EOF;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-05-28 19:56:29 +02:00
|
|
|
fcinfo.arg[i] = PointerGetDatum(p);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-10-24 22:59:35 +02:00
|
|
|
/*
|
|
|
|
* Now that we've eaten the input message, check to see if we actually
|
|
|
|
* want to do the function call or not.
|
|
|
|
*
|
|
|
|
* Currently, we report an error if in ABORT state, or return a dummy
|
|
|
|
* NULL response if fastpath support has been compiled out.
|
|
|
|
*/
|
|
|
|
if (IsAbortedTransactionBlockState())
|
|
|
|
elog(ERROR, "current transaction is aborted, "
|
|
|
|
"queries ignored until end of transaction block");
|
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
#ifdef NO_FASTPATH
|
|
|
|
/* force a NULL return */
|
|
|
|
retval = (Datum) 0;
|
|
|
|
fcinfo.isnull = true;
|
1996-07-09 08:22:35 +02:00
|
|
|
#else
|
2000-05-28 19:56:29 +02:00
|
|
|
retval = FunctionCallInvoke(&fcinfo);
|
1998-09-01 06:40:42 +02:00
|
|
|
#endif /* NO_FASTPATH */
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
if (fcinfo.isnull)
|
|
|
|
SendFunctionResult(retval, fip->retbyval, 0);
|
|
|
|
else
|
|
|
|
SendFunctionResult(retval, fip->retbyval, fip->retlen);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|