Re: What happened to the is_ family of functions proposal?
От | Andres Freund |
---|---|
Тема | Re: What happened to the is_ |
Дата | |
Msg-id | 201009220109.29700.andres@anarazel.de обсуждение исходный текст |
Ответ на |
Re: What happened to the is_ |
Ответы |
Re: What happened to the is_ |
Список | pgsql-hackers |
On Wednesday 22 September 2010 01:05:39 Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > 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. > > There are many rules that you could possibly make for type input > functions. But "you cannot throw an error" is not one of them --- > or at least, not one that you can usefully expect to be followed > for anything more than trivial straightline code. > > The poster child for this is of course domain_in(). But even without > that, I don't think you can realistically legislate that no errors be > thrown by something of the complexity of, say, the timestamp input > functions. Just for starters, what of a palloc() failure? Uhm. Isnt a palloc failure a really, really bad example because it will kill the session anyway? FATAL+ is not relevant in that context, right? Andres
В списке pgsql-hackers по дате отправления: