I wrote: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> I think you are confusing parsing of the string literal that >> is the argument of CREATE FUNCTION with the parsing that the plpgsql >> interpreter does on the function body once it gets it. > Oh, I'm not confused about that at all. I'm arguing that it's a bad > idea. To be more explicit, I see that there is a third parser phase -- when the function is planned, the original contents of the character string literal are passed to the normal PostgreSQL execution engine, which parses them again, potentially using different rules from those used by the plpgsql interpreter. I maintain that having the execution engine use different rules for looking at the value of the literal than the plpgsql parser used to find the boundaries of the literal is where the weird corner case bugs come in. For someone using string literal '\x49\\' in a plpgsql function, the plpgsql parser sees it as a two character string, but when the function is actually run, depending on whether the first execution is using standard string literals, this can be either a two character or a six character string. Unless the coder of the function uses the SET option in declaring the function, they don't know what value will be used at run time, and it may change from run to run. It seems to me that we already have exactly the kinds of problems you say you want to avoid, and that there is an obvious fix to avoid them. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers