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:
http://www.postgresql.org/mailpref/pgsql-hackers
