Re: proposal: PL/Pythonu - function ereport
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: PL/Pythonu - function ereport |
| Дата | |
| Msg-id | CAFj8pRDk0zspJ1yd-FBx3m5vNzs8epQYx92pU4y19s_+zU8GoQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: PL/Pythonu - function ereport (Catalin Iacob <iacobcatalin@gmail.com>) |
| Ответы |
Re: proposal: PL/Pythonu - function ereport
|
| Список | pgsql-hackers |
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=#
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.
В списке pgsql-hackers по дате отправления: