Re: proposal: PL/Pythonu - function ereport

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: PL/Pythonu - function ereport
Дата
Msg-id CAFj8pRBCz14q_rY+d9dDzTwgpc1BTWoSstjkKcMnQFv8D8vbMw@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
Hi

2016-02-17 7:34 GMT+01:00 Catalin Iacob <iacobcatalin@gmail.com>:
After I unzip the patch it doesn't apply.
patch says:
patch: **** Only garbage was found in the patch input.

It's a combined diff, the git-diff manual says this about it:
Chunk header format is modified to prevent people from accidentally
feeding it to patch -p1. Combined diff format was created for review
of merge commit changes, and was not meant for apply.

Thanks for doing the test changes. It definitely shows the change is
big. The tests at least were heavily relying on both the str
conversion and on passing more than one argument. Sad face. 

You're going to hate me but seeing this I changed my mind about 5,
requiring all those extra str calls is too much change in behaviour. I
was going to propose passing everything through str (so message,
detail, hint but also schema, table) but thinking about it some more,
I think I have something better.

Ok, it is no problem - this work is +/- research, and there are not direct way often :)
 

Python 3 has keyword only arguments. It occurs to me they're exactly
for "optional extra stuff" like detail, hint etc.
Python 2 doesn't have that notion but you can kind of fake it since
you get an args tuple and a kwargs dictionary.

I prefer a possibility to use both ways - positional form is shorter, keywords can help with some parameters.

But I cannot to imagine your idea, can you show it in detail?
 

What about keeping the same behaviour for multiple positional
arguments (single one -> make it str, multiple -> use str of the args
tuple) and requiring users to pass detail, hint only as keyword
arguments? Code wise it would only mean adding PyObject* kw to
PLy_output and adding some code to extract detail, hint etc. from kw.
This would also allow getting rid of the GUC since backward
compatibility is fully preserved.

Again, sorry for all the back and forth but it still feels like we
haven't nailed the design to something satisfactory. All the tests you
needed to change are a hint towards that.

It not any problem. I am thankful for cooperation.

Regards

Pavel

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Следующее
От: Artur Zakirov
Дата:
Сообщение: Re: Fuzzy substring searching with the pg_trgm extension