Prev: pgstatindex still throws ERROR: value "3220078592" is out of range for type integer
Next: [HACKERS] Performance of Bit String
From: Heikki Linnakangas on 30 Jun 2010 14:14 On 23/06/10 21:36, Robert Haas wrote: > On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> On 15/06/10 10:31, Heikki Linnakangas wrote: >>> >>> You could avoid changing the meaning of fn_expr by putting the check in >>> the parse analysis phase, into transformFuncCall(). That would feel >>> safer at least for back-branches. >> >> Here's a patch using that approach. >> >> I grepped through PostgreSQL and pgadmin source code to find the system >> columns where valid node-strings are stored: >> >> pg_index.indexprs >> pg_index.indprep >> pg_attrdef.adbin >> pg_proc.proargdefaults >> pg_constraint.conbin >> >> Am I missing anything? > > I think that pg_type.typdefaultbin is used by pg_dump. Yep, added that. > pg_rewrite.ev_qual, pg_rewrite.ev_action, pg_trigger.tgqual also > contain nodeToString() output but I didn't have any luck using them > with pg_get_expr() so maybe they don't need to be included. I left them out. > The only other thing I notice is that, obviously, the FIXME comment > needs to be FIXMEd before commit. Fixed. > I'd still be in favor of inserting at least some basic error checks > into readfuncs.c, though just in HEAD. The restrictions implemented > here seem adequate to prevent a security vulnerability, but superusers > can still invoke those functions manually, and while superusers can > clearly crash the system in any number of ways, that doesn't seem (to > me) like an adequate justification for ignoring the return value of > strtok(). YMMV, of course. Agreed. I'll do that as a separate patch. Thanks for the review! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |