Re: Hm, table constraints aren't so unique as all that
От | Tom Lane |
---|---|
Тема | Re: Hm, table constraints aren't so unique as all that |
Дата | |
Msg-id | 13134.1359429837@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Hm, table constraints aren't so unique as all that (Peter Geoghegan <peter.geoghegan86@gmail.com>) |
Ответы |
Re: Hm, table constraints aren't so unique as all that
Re: Hm, table constraints aren't so unique as all that Re: Hm, table constraints aren't so unique as all that |
Список | pgsql-hackers |
Peter Geoghegan <peter.geoghegan86@gmail.com> writes: > On 29 January 2013 00:25, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Of course this wouldn't be material for back-patching, but it seems to >> me there's still time to fix this for 9.3, and we should do so if we >> want to claim that the enhanced-errors patch uniquely identifies >> constraints. > I can see the case for fixing this, but I don't feel that it's > particularly important that constraints be uniquely identifiable from > the proposed new errdata fields. I think that we'll soon be buried in gripes if they're not. Pretty much the whole point of this patch is to allow applications to get rid of ad-hoc, it-usually-works coding techniques. I'd argue that not checking the entire constraint identity is about as fragile as trying to "sed" the constraint name out of a potentially-localized error message. In both cases, it often works fine, until the application's context changes. regards, tom lane
В списке pgsql-hackers по дате отправления: