On Tue, Sep 21, 2010 at 1:45 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Tue, Sep 21, 2010 at 6:02 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> So we could refactor the input functions so that there's an internal
>> function that returns the accepted datum in the OK case and an ErrorData
>> for the failure case. The regular input function would just throw the
>> error data in the latter case; but this would allow another function to
>> just return whether it worked or not.
>
> You're assuming the input function won't have any work it has to undo
> which it would need the savepoint for anyways. For most of the
> built-in datatypes -- all of the ones intended for holding real data
> -- that's true. But for things like regclass or regtype it might not
> be and for user-defined data types.... who knows?
>
> Of course all people really want is to test whether something is a
> valid integer, floating point value, etc.
Right. Or a date - that's a case that comes up for me pretty
frequently. It's not too hard to write a regular expression to test
whether something is an integer -- although there is the question of
whether it will overflow, which is sometimes relevant -- but a date or
timestamp field is a bit harder.
I don't understand the argument that we need type input functions to
be protected by a savepoint. That seems crazy to me. We're taking a
huge performance penalty here to protect against something that seems
insane to me in the first instance. Not to mention cutting ourselves
off from really important features, like the ability to recover from
errors during COPY. I don't understand why we can't just make some
rules about what type input functions are allowed to do. And if you
break those rules then you get to keep both pieces. Why is this
unreasonable? A savepoint can hardly protect you against damage
inflicted by the execution of arbitrary code; IOW, we're already
relying on the user to follow some rules.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company