Re: proposal: PL/Pythonu - function ereport

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: PL/Pythonu - function ereport
Дата
Msg-id CAFj8pRBuKzn=ZRCge7CMVi4PkWG5i4awaDDV=WJ9B6VB+d9m_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: PL/Pythonu - function ereport  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: PL/Pythonu - function ereport
Список pgsql-hackers
Hi

2016-02-29 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:



0003 is the most controversial. It removes the ability to pass message
as keyword argument. My reasoning was that keyword arguments are
usually optional and configure extra aspects of the function call
while message is required and fundamental so therefore it should be
positional. If you allow it as keyword as well, you have to deal with
the ambiguity of writing plpy.info('a message', message='a keyword arg
message, does this overwrite the first one or what?').

I though about it before and I prefer variant with possibility to enter message as keyword parameter. The advantage of this solution is simple usage dictionary value as parameter with possibility to set all fields.

We can check collision and we can raise a error. Same technique is used in plpgsql:

postgres=# do $$ begin raise warning 'kuku' using message='NAZDAR'; end; $$;
ERROR:  RAISE option already specified: MESSAGE
CONTEXT:  PL/pgSQL function inline_code_block line 1 at RAISE
postgres=#

What do you think?

Pavel
 

For the code with my patches on top on I ran the PL/Python tests for
2.4, 2.5, 2.6, 2.7 and 3.5. Everything passed.

Can you have a look at the patches, fold the ones you agree with on
top of yours and send the final version? With that I think this will
be Ready for Committer.


I merged your patches without @3 (many thanks for it). Instead @3 I disallow double message specification (+regress test)

Regards

Pavel
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: snapshot too old, configured by time
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.