Re: proposal: PL/Pythonu - function ereport

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: PL/Pythonu - function ereport
Дата
Msg-id CAFj8pRDsGe4L-S9XNiWMvvmhQgJLOKqHT7omNfu0t9rKdPZqyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
Ответы Re: proposal: PL/Pythonu - function ereport  (Catalin Iacob <iacobcatalin@gmail.com>)
Список pgsql-hackers
<p dir="ltr"><br /> Dne 2. 2. 2016 7:30 napsal uživatel "Catalin Iacob" <<a
href="mailto:iacobcatalin@gmail.com">iacobcatalin@gmail.com</a>>:<br/> ><br /> > On Mon, Feb 1, 2016 at 5:37
PM,Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>> wrote:<br /> > >
Dne29. 1. 2016 18:09 napsal uživatel "Catalin Iacob"<br /> > > <<a
href="mailto:iacobcatalin@gmail.com">iacobcatalin@gmail.com</a>>:<br/> > >> Looking at the output above, I
don'tsee who would rely on calling<br /> > >> plpy.error with multiple arguments and getting the tuple so
I'm<br/> > >> actually in favor of just breaking backward compatibility. Note that<br /> > >> passing
multiplearguments isn't even documented. So I would just<br /> > >> change debug, info, error and friends to
dowhat raise_debug,<br /> > >> raise_info, raise_error do. With a single argument behavior stays the<br />
>>> same, with multiple arguments one gets more useful behavior (detail,<br /> > >> hint) instead of
theuseless tuple. That's my preference but we can<br /> > >> leave the patch with raise and leave the decision
tothe committer.<br /> > >><br /> > ><br /> > > if breaking compatibility, then raise* functions
areuseless, and should be<br /> > > removed.<br /> ><br /> > Indeed. I think it's better to change the
existingfunctions and break<br /> > compatibility instead of adding the raise_ functions. But the<br /> >
committerwill decide if that's what should be done. Since you wrote<br /> > the patch with raise_* I propose you
keepit that way for now and let<br /> > the committer decide. I wrote the doc patch based on raise_* as well.<p
dir="ltr">Ifwe decided to break compatibility, then we have to do explicitly. Thid discussion can continue with
commiter,but send path with duplicitly defined functions has not sense for me. Currently I out of office, so I cannot
toclean it. 4.2 I should to work usually<p dir="ltr">><br /> > Attached is the doc patch (made on top of your
patch).I'll wait for<br /> > you to combine them and switch to raising Error and then hopefully<br /> > this is
readyfor a committer to look at.<br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_lsn cast to/from int8