On 2/4/16 3:13 AM, Catalin Iacob wrote:

Thanks for the overview. Very helpful.

I find existing behaviour for 2, 3 and 4 unlike other Python APIs I've
seen, surprising and not very useful. If I want to log a tuple I can
construct and pass a single tuple, I don't see why plpy.info() needs
to construct it for me. And for the documented, single argument call
nothing changes.

Agreed, that usage is wonky.

The question to Bruce (and others) is: is it ok to change to the new
behaviour illustrated and change meaning for usages like 2, 3 and 4?

If any users have a bunch of code that depends on the old behavior, they're going to be rather irritated if we break it. If we want to depricate it then I think we need a GUC that allows you to get the old behavior back.

If we don't want that, the solution Pavel and I see is introducing a
parallel API named plpy.raise_info or plpy.rich_info or something like
that with the new behaviour and leave the existing functions
unchanged. Another option is some compatibility GUC but I don't think
it's worth the trouble and confusion.

If we're going to provide an alternative API, I'd just do plpy.raise(LEVEL, ...).

At this point, my vote would be:

Add a plpython.ereport_mode GUC that has 3 settings: current (deprecated) behavior, allow ONLY 1 argument, new behavior. The reason for the 1 argument option is it makes it much easier to find code that's still using the old behavior. I think it's also worth having plpy.raise(LEVEL, ...) as an alternative.

If folks feel that's overkill then I'd vote to leave the existing behavior alone and just add plpy.raise(LEVEL, ...).
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to