On Tue, Sep 21, 2010 at 1:45 PM, Greg Stark <gsst...@mit.edu> wrote: > On Tue, Sep 21, 2010 at 6:02 PM, Alvaro Herrera > <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
