On 15/06/10 15:19, Florian Pflug wrote:
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.
Yeah, that would be quite elegant. I think it's too late for 9.0, but
something to consider in the future.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
