> 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.
>

Reply via email to