I see the problem.  Your 7.0.3 dump contains several instances of this
pattern:

CREATE TABLE "users_alertable" (
        "user_id" int4,
        "email" character varying(100),
        "first_names" character varying(100),
        "last_name" character varying(100),
        "password" character varying(30)
);

...

CREATE FUNCTION "user_vacations_kludge" (int4 ) RETURNS int4 AS '
begin
 return count(*) 
   from user_vacations v, users u
   where u.user_id = $1 and v.user_id = u.user_id
   and current_timestamp between v.start_date and v.end_date;
end;' LANGUAGE 'plpgsql';

...

CREATE RULE "_RETusers_alertable" AS ON SELECT TO users_alertable DO INSTEAD SELECT 
u.user_id, u.email, u.first_names, u.last_name, u."password" FROM users u WHERE 
(((((u.on_vacation_until ISNULL) OR (u.on_vacation_until < "timestamp"('now'::text))) 
AND (u.user_state = 'authorized'::"varchar")) AND ((u.email_bouncing_p ISNULL) OR 
(u.email_bouncing_p = 'f'::bpchar))) AND (user_vacations_kludge(u.user_id) = 0));

Although this works fine, 7.1 folds the table + rule down into a single
CREATE VIEW, which comes before the CREATE FUNCTION because that's what
the OID ordering suggests will work.  Ugh.

A possible kluge answer is to make pg_dump's OID-ordering of views
depend on the OID of the view rule rather than the view relation.
I am not sure if that would break any cases that work now, however.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to