Re: What happened to the is_ family of functions proposal?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: What happened to the is_ family of functions proposal?
Дата
Msg-id 201009220109.29700.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: What happened to the is_ family of functions proposal?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: What happened to the is_ family of functions proposal?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: What happened to the is_ family of functions proposal?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: What happened to the is_ family of functions proposal?