Gavin Sherry wrote:
> Attached is a patch implementing:
>
> create or replace rule ...
> create or replace view ...
>
> It passes all regression tests. There's only one really sketchy part of
> the patch: UpdateAttributeTuples(). This routine is fairly dangerous since
> it simply removes a given relid's pg_attribute entries and creates a new
> set basic on a given TupleDesc. Naturally, it is only useful for views.
>
This might be useful for the new named composite type feature also.
Assuming both of our patches get accepted, I'll look at implementing
CREATE OR REPLACE TYPE blah AS (...)
It'll be tough getting it into 7.3 though.
This just raised a question in my mind though. In nodeFunctionscan,
function_getonetuple(), I recently added the following in support of
anonymous composite types:
if (returnsTuple)
{
slot = (TupleTableSlot *) retDatum;
/*
* if function return type was RECORD, we need to check to be
* sure the structure from the query matches the actual return
* structure
*/
if (fn_typtype == 'p' && fn_typeid == RECORDOID)
if (tupledesc_mismatch(tupdesc, slot->ttc_tupleDescriptor))
elog(ERROR, "Query-specified return tuple and actual"
" function return tuple do not match");
Should this check be applied *whenever* a function returns a tuple,
whether or not the function returns RECORD? Maybe:
if (returnsTuple)
{
slot = (TupleTableSlot *) retDatum;
/*
* we need to check to be sure the specified structure matches
* the actual return structure
*/
if (tupledesc_mismatch(tupdesc, slot->ttc_tupleDescriptor))
elog(ERROR, "specified column definitions and actual"
" return column definitions do not match");
Comments?
Joe
