From: Florian Pflug on 15 Jun 2010 08:19 On Jun 15, 2010, at 9: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. For 9.0, wouldn't a cleaner way to accomplish this be a seperate type for expressions, say pg_expr, instead of storing them as text? With an input function that unconditionally raises and error and no cast to pg_expr, creating new instances of that type would be impossible for normal users. The output function and casts to text would call pg_get_expr() with zero as the second argument. The internal representation wouldn't change, it's just the type's OID in the catalog that'd be different. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: [HACKERS] debug log in pg_archivecleanup Next: [HACKERS] New PGXN Extension site |