Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-06-10 20:56 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I noticed that this new feature in PL/Python gratuitously uses slightly > different keyword names than the C and PL/pgSQL APIs, e.g. "schema" instead > of "schema_name" etc. I propose to fix that with the attached

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I noticed that this new feature in PL/Python gratuitously uses slightly different keyword names than the C and PL/pgSQL APIs, e.g. "schema" instead of "schema_name" etc. I propose to fix that with the attached patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Deve

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Pavel Stehule writes: > here is patch Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-04-08 20:54 GMT+02:00 Pavel Stehule : > > > 2016-04-08 20:52 GMT+02:00 Tom Lane : > >> Pavel Stehule writes: >> > 2016-04-08 17:38 GMT+02:00 Teodor Sigaev : >> >> thank you, pushed. Pls, pay attention to buildfarm. >> >> > Thank you very much for commit. >> >> According to buildfarm memb

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-04-08 20:52 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2016-04-08 17:38 GMT+02:00 Teodor Sigaev : > >> thank you, pushed. Pls, pay attention to buildfarm. > > > Thank you very much for commit. > > According to buildfarm member prairiedog, there's a problem in one > of the test cases.

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Pavel Stehule writes: > 2016-04-08 17:38 GMT+02:00 Teodor Sigaev : >> thank you, pushed. Pls, pay attention to buildfarm. > Thank you very much for commit. According to buildfarm member prairiedog, there's a problem in one of the test cases. I suspect that it's using syntax that doesn't exist i

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-04-08 17:38 GMT+02:00 Teodor Sigaev : > Thank you very much >> > > thank you, pushed. Pls, pay attention to buildfarm. > Thank you very much for commit. And big thanks to Iacob for big help. Regards Pavel > > -- > Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Thank you very much thank you, pushed. Pls, pay attention to buildfarm. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Mar 2, 2016 at 12:01 AM, Pavel Stehule wrote: >> I see the pfree you added isn't allowed on a NULL pointer but as far >> as I see message is guaranteed not to be NULL as dgettext never >> returns NULL. >> >> I'll mark this Ready for Committer. > > Thank you very much This patch needs a co

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-03-01 18:48 GMT+01:00 Catalin Iacob : > On 3/1/16, Pavel Stehule wrote: > >> I though about it before and I prefer variant with possibility to enter > >> message as keyword parameter. > > That's also ok, but indeed with a check that it's not specified twice > which I see you already adde

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 3/1/16, Pavel Stehule wrote: >> I though about it before and I prefer variant with possibility to enter >> message as keyword parameter. That's also ok, but indeed with a check that it's not specified twice which I see you already added. > I merged your patches without @3 (many thanks for it)

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-02-29 17:53 GMT+01:00 Pavel Stehule : > > > >> 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 f

Re: [HACKERS] proposal: PL/Pythonu - function ereport

> 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

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/26/16, Pavel Stehule wrote: > Sending updated version I did some changes on top of your last version as that was easier than commenting about them, see attached. 0001 and 0005 are comment changes. 0002 is really needed, without it the tests fail on Python2.4. 0004 removes more code relate

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-02-25 7:06 GMT+01:00 Catalin Iacob : > On Fri, Feb 19, 2016 at 9:41 PM, Pavel Stehule > wrote: > > It looks like good idea. Last version are not breaking compatibility - > and > > I think so it can works. > > > > I wrote the code, that works on Python2 and Python3 > > Hi, > > I've attached

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Fri, Feb 19, 2016 at 9:41 PM, Pavel Stehule wrote: > It looks like good idea. Last version are not breaking compatibility - and > I think so it can works. > > I wrote the code, that works on Python2 and Python3 Hi, I've attached a patch on top of yours with some documentation improvements, f

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-02-18 17:59 GMT+01:00 Catalin Iacob : > On 2/18/16, Pavel Stehule wrote: > > it doesn't look badly. Is there any possibility how to emulate it with > > Python2 ? What do you think about some similar implementation on Python2? > > The example code I gave works as is in Python2. > > The Python

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/18/16, Pavel Stehule wrote: > it doesn't look badly. Is there any possibility how to emulate it with > Python2 ? What do you think about some similar implementation on Python2? The example code I gave works as is in Python2. The Python3 keyword only arguments are only syntactic sugar. See h

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-02-17 16:54 GMT+01:00 Catalin Iacob : > On Wed, Feb 17, 2016 at 3:32 PM, Pavel Stehule > wrote: > >> Python 3 has keyword only arguments. It occurs to me they're exactly > >> for "optional extra stuff" like detail, hint etc. > >> Python 2 doesn't have that notion but you can kind of fake it

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Feb 17, 2016 at 3:32 PM, Pavel Stehule wrote: >> Python 3 has keyword only arguments. It occurs to me they're exactly >> for "optional extra stuff" like detail, hint etc. >> Python 2 doesn't have that notion but you can kind of fake it since >> you get an args tuple and a kwargs dictionary

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-02-17 7:34 GMT+01:00 Catalin Iacob : > After I unzip the patch it doesn't apply. > patch says: > patch: Only garbage was found in the patch input. > > It's a combined diff, the git-diff manual says this about it: > Chunk header format is modified to prevent people from accidentally >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

After I unzip the patch it doesn't apply. patch says: patch: Only garbage was found in the patch input. It's a combined diff, the git-diff manual says this about it: Chunk header format is modified to prevent people from accidentally feeding it to patch -p1. Combined diff format was created f

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I noticed the patch isn't registered in the March CF, please do that. > It would be a pity to miss 9.6 because of not registering it in time. > https://commitfest.postgresql.org/9/525/ Regards Pavel

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-02-16 17:18 GMT+01:00 Catalin Iacob : > On Sat, Feb 13, 2016 at 4:26 PM, Pavel Stehule > wrote: > > I am sending new version. Current version does: > > Hello, > > I had a look and I like the big picture. > > Tests fail when built against Python 3.5 with stuff like this in > regression.di

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-02-16 21:06 GMT+01:00 Catalin Iacob : > On Tue, Feb 16, 2016 at 5:18 PM, Catalin Iacob > wrote: > > We have > > elog_test_legacy to test elog_test_legacy=true, the rest of the tests > > should use legacy_custom_exception=false. > > This should have been: > We have elog_test_legacy to test le

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 16, 2016 at 5:18 PM, Catalin Iacob wrote: > We have > elog_test_legacy to test elog_test_legacy=true, the rest of the tests > should use legacy_custom_exception=false. This should have been: We have elog_test_legacy to test legacy_custom_exception=true, the rest of the tests should us

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Sat, Feb 13, 2016 at 4:26 PM, Pavel Stehule wrote: > I am sending new version. Current version does: Hello, I had a look and I like the big picture. Tests fail when built against Python 3.5 with stuff like this in regression.diffs: -ERROR: plpy.Error: stop on error -DETAIL: some detail -HI

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi I am sending new version. Current version does: 1. the plpy utility functions can use all ErrorData fields, 2. there are no new functions, 3. via GUC plpythonu.legacy_custom_exception we can return previous behave, 4. only exception Error is raised with natural structure - no composite value s

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/10/16 12:44 PM, Pavel Stehule wrote: FWIW, I'd think it's better to not break backwards compatibility, but I'm also far from a python expert. It might well be worth adding a plpython GUC to control the behavior so that there's a migration path forward, or maybe do something

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi > >> Actually I imagine that if there's no agreement between author and first >> reviewer, there might not *be* a committer in the first place. Perhaps >> try to get someone else to think about it and make a decision. It is >> possible that some other committer is able to decide by themselv

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I don't think we need to preserve absolutely all the existing behavior to the letter. We do need to preserve the behavior for sensible cases that people might be reasonably be using currently; and if there's anything somewhat obscure but really useful that you currently get by using some clever tr

Re: [HACKERS] proposal: PL/Pythonu - function ereport

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 cons

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 11:52 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> The eventual committer is likely to be much happier with this patch if >> you guys have achieved consensus among yourselves on the best >> approach. > > Actually I imagine that if there's no agreement between author and

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/2/16 4:52 PM, Alvaro Herrera wrote: Robert Haas wrote: The eventual committer is likely to be much happier with this patch if you guys have achieved consensus among yourselves on the best approach. (Disclaimer: The eventual committer won't be me. I'm not a Python guy. But we try to proc

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Robert Haas wrote: > The eventual committer is likely to be much happier with this patch if > you guys have achieved consensus among yourselves on the best > approach. > > (Disclaimer: The eventual committer won't be me. I'm not a Python > guy. But we try to proceed by consensus rather than com

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 10:39 AM, Catalin Iacob wrote: > On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule wrote: >> If we decided to break compatibility, then we have to do explicitly. Thid >> discussion can continue with commiter, but send path with duplicitly defined >> functions has not sense for

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule wrote: > If we decided to break compatibility, then we have to do explicitly. Thid > discussion can continue with commiter, but send path with duplicitly defined > functions has not sense for me. Currently I out of office, so I cannot to > clean it. 4.

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Dne 2. 2. 2016 7:30 napsal uživatel "Catalin Iacob" : > > On Mon, Feb 1, 2016 at 5:37 PM, Pavel Stehule wrote: > > Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" > > : > >> Looking at the output above, I don't see who would rely on calling > >> plpy.error with multiple arguments and getting

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Mon, Feb 1, 2016 at 5:37 PM, Pavel Stehule wrote: > Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" > : >> Looking at the output above, I don't see who would rely on calling >> plpy.error with multiple arguments and getting the tuple so I'm >> actually in favor of just breaking backward c

Re: [HACKERS] proposal: PL/Pythonu - function ereport

hi I am sorry, I am writing from mobile phone and I cannot to cutting text well. Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" < iacobcata...@gmail.com>: This interface is new generation of previous > > functions: info, notice, warning, error with keyword parameters interface. I > > didn'

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Jan 26, 2016 at 5:42 PM, Pavel Stehule wrote: > I removed from previous patch all OOP related changes. New patch contains > raise_ functions only. This interface is new generation of previous > functions: info, notice, warning, error with keyword parameters interface. I > didn't change

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi > > > I though about it lot of, and I see a the core of problems in orthogonal > > constructed exceptions in Python and Postgres. We working with statements > > elog, ereport, RAISE EXCEPTION - and these statements are much more like > > templates - can generate any possible exception. Python

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On recent occasions, Pavel Stehule and Catalin Iacob have written: ... >> But *inside* PLPython what I wrote is true, see this example for what I >> mean: >> >> CREATE FUNCTION test() >> RETURNS int >> AS $$ >> def a_func(): >> raise plpy.Error('an error') >> >> try: >> a_func() >>

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi >>> But in my opinion this discussion shouldn't really even be about >>> catching these things, most of the times you won't catch them and >>> instead you'll let them go to Postgres. The discussion should be >>> whether raise plpy.Error(...), plpy.raise_error, plpy.raise_info(,,,) >>> etc. all

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-26 8:22 GMT+01:00 Pavel Stehule : > > > 2016-01-26 7:31 GMT+01:00 Catalin Iacob : > >> On 1/21/16, Pavel Stehule wrote: >> > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : >> >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via >> >> plpy.execute) -> SQL code 2 -> PL/Python

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-26 7:31 GMT+01:00 Catalin Iacob : > On 1/21/16, Pavel Stehule wrote: > > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : > >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via > >> plpy.execute) -> SQL code 2 -> PL/Python code 2 > >> > >> If I'm writing PL/Python code 1 and

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/21/16, Pavel Stehule wrote: > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via >> plpy.execute) -> SQL code 2 -> PL/Python code 2 >> >> If I'm writing PL/Python code 1 and I want to raise an error toward >> SQL code 1 I use rai

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/21/16 4:57 PM, Pavel Stehule wrote: It is not correct - outside PLPython you got a Error (PostgreSQL error has not any classes), and isn't important the raising class (Error or SPIError). Inside PL/Python you will got SPIError or successors (based on SQLcode). Right. The closest thing we h

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-14 17:16 GMT+01:00 Catalin Iacob : > On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby > wrote: > > On 1/12/16 11:25 AM, Catalin Iacob wrote: > >> They're similar but not really the same thing. raise Error and > >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is > >> raise

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby wrote: > On 1/12/16 11:25 AM, Catalin Iacob wrote: >> They're similar but not really the same thing. raise Error and >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is >> raised when coming back after calling into Postgres to execut

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/12/16 11:25 AM, Catalin Iacob wrote: >The differentiation between Error and SPIError is wrong, because there isn't >any difference in reality. They're similar but not really the same thing. raise Error and plpy.error are both ways to call ereport(ERROR, ...) while SPIError is raised when co

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Mon, Jan 11, 2016 at 7:33 PM, Pavel Stehule wrote: > I see it. > > it looks like distinguish between Error and SPIError is wrong way. And I > have any other ugly use case. > > If I raise a Error from one PLPythonu function, then in other PLPython > function I'll trap a SPIError exception, becau

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-12 17:59 GMT+01:00 Catalin Iacob : > On Tue, Jan 12, 2016 at 5:50 PM, Pavel Stehule > wrote: > > Error and Fatal exception classes are introduced in my patch - it was > Peter' > > request (if I remember it well), and now I am thinking so it is not good > > idea. > > Now everybody is confu

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Jan 12, 2016 at 5:50 PM, Pavel Stehule wrote: > Error and Fatal exception classes are introduced in my patch - it was Peter' > request (if I remember it well), and now I am thinking so it is not good > idea. Now everybody is confused :). Your patch does: -PLy_exc_error = PyErr_NewExc

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-11 20:11 GMT+01:00 Jim Nasby : > On 1/11/16 12:46 PM, Pavel Stehule wrote: > >> 2016-01-11 19:41 GMT+01:00 Jim Nasby > >: >> >> On 1/11/16 12:33 PM, Pavel Stehule wrote: >> >> 1. break compatibility and SPIError replace by Error >> >> >> At

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/11/16 12:46 PM, Pavel Stehule wrote: 2016-01-11 19:41 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/11/16 12:33 PM, Pavel Stehule wrote: 1. break compatibility and SPIError replace by Error At this point I've lost track... what's the incompatibility between

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-11 19:41 GMT+01:00 Jim Nasby : > On 1/11/16 12:33 PM, Pavel Stehule wrote: > >> 1. break compatibility and SPIError replace by Error >> > > At this point I've lost track... what's the incompatibility between the > two? > the name and internal format (but this structure can be visible to u

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/11/16 12:33 PM, Pavel Stehule wrote: 1. break compatibility and SPIError replace by Error At this point I've lost track... what's the incompatibility between the two? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-11 17:05 GMT+01:00 Catalin Iacob : > On Fri, Jan 8, 2016 at 7:56 AM, Pavel Stehule > wrote: > >> 3. PLy_error__init__ is used for BaseError but always sets an > >> attribute called spidata, I would expect that to only happen for > >> SPIError not for BaseError. You'll need to pick some ot

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Fri, Jan 8, 2016 at 7:56 AM, Pavel Stehule wrote: >> 3. PLy_error__init__ is used for BaseError but always sets an >> attribute called spidata, I would expect that to only happen for >> SPIError not for BaseError. You'll need to pick some other way of >> attaching the error details to BaseError

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-08 7:31 GMT+01:00 Catalin Iacob : > shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule > wrote: > > here is new version. > > And here's a new review, sorry for the delay. > > > Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So > > plpy.SPIError isn't descendant o

Re: [HACKERS] proposal: PL/Pythonu - function ereport

shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule wrote: > here is new version. And here's a new review, sorry for the delay. > Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So > plpy.SPIError isn't descendant of plpy.Error and then there are not possible > incompatib

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi here is new version. Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So plpy.SPIError isn't descendant of plpy.Error and then there are not possible incompatibility issues. Instead modification builtin function plpy.debug, plpy.info, ... and introduction incompatibility

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-12-08 7:06 GMT+01:00 Catalin Iacob : > On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule > wrote: > > Don't understand - if Fatal has same behave as Error, then why it cannot > be > > inherited from Error? > > > > What can be broken? > > Existing code that did "except plpy.Error as exc" will

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-12-08 7:06 GMT+01:00 Catalin Iacob : > On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule > wrote: > > Don't understand - if Fatal has same behave as Error, then why it cannot > be > > inherited from Error? > > > > What can be broken? > > Existing code that did "except plpy.Error as exc" will

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule wrote: > Don't understand - if Fatal has same behave as Error, then why it cannot be > inherited from Error? > > What can be broken? Existing code that did "except plpy.Error as exc" will now also be called if plpy.Fatal is raised. That wasn't the cas

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-12-03 16:57 GMT+01:00 Catalin Iacob : > On Thu, Dec 3, 2015 at 7:58 AM, Pavel Stehule > wrote: > > I am sorry, I don't understand. Now due inheritance plpy.Fatal and > > plpy.SPIError has availability to use keyword parameters. > > Indeed, I didn't realize this, but I don't think it changes

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Thu, Dec 3, 2015 at 7:58 AM, Pavel Stehule wrote: > I am sorry, I don't understand. Now due inheritance plpy.Fatal and > plpy.SPIError has availability to use keyword parameters. Indeed, I didn't realize this, but I don't think it changes the main argument. What I think should happen: 1. Err

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-12-03 7:04 GMT+01:00 Catalin Iacob : > On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule > wrote: > > here is complete patch - regress tests for all supported Python branches > > I had a look at what changed in v10 since my last reviewed version and > indeed most of it is straightforward: rename

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule wrote: > here is complete patch - regress tests for all supported Python branches I had a look at what changed in v10 since my last reviewed version and indeed most of it is straightforward: renames from SPIError to Error. The patch also changes plpy.

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi > >> > Do you have some ideas about the name of this class? >> >> I think plpy.Error is fine. >> >> > here is updated patch - work with 2.x Python. > > I have 3.x Python broken on my fedora, so I should not do tests on 3.x. > here is complete patch - regress tests for all supported Python bran

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-29 13:42 GMT+01:00 Michael Paquier : > > > On Sun, Nov 29, 2015 at 4:00 PM, Pavel Stehule > wrote: > >> 2015-11-28 13:11 GMT+01:00 Michael Paquier : >> >>> On Sat, Nov 28, 2015 at 1:57 AM, Pavel Stehule >>> wrote: >>> > >>> > >>> > 2015-11-27 17:54 GMT+01:00 Teodor Sigaev : >>> >> >>> >>

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Sun, Nov 29, 2015 at 4:00 PM, Pavel Stehule wrote: > 2015-11-28 13:11 GMT+01:00 Michael Paquier : > >> On Sat, Nov 28, 2015 at 1:57 AM, Pavel Stehule >> wrote: >> > >> > >> > 2015-11-27 17:54 GMT+01:00 Teodor Sigaev : >> >> >> >> Is this patch in 'Waiting on Author' state actually? >> >> I am

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-11-16 23:40 GMT+01:00 Peter Eisentraut : > On 11/15/15 11:29 PM, Pavel Stehule wrote: > > > > > > 2015-11-16 5:20 GMT+01:00 Peter Eisentraut > >: > > > > I don't think it's right to reuse SPIError for this. SPIError is > > clearly meant to signal an error

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-28 13:11 GMT+01:00 Michael Paquier : > On Sat, Nov 28, 2015 at 1:57 AM, Pavel Stehule > wrote: > > > > > > 2015-11-27 17:54 GMT+01:00 Teodor Sigaev : > >> > >> Is this patch in 'Waiting on Author' state actually? > > I am marking it as returned with feedback for this CF then. > please, c

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Sat, Nov 28, 2015 at 1:57 AM, Pavel Stehule wrote: > > > 2015-11-27 17:54 GMT+01:00 Teodor Sigaev : >> >> Is this patch in 'Waiting on Author' state actually? I am marking it as returned with feedback for this CF then. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-27 17:54 GMT+01:00 Teodor Sigaev : > Is this patch in 'Waiting on Author' state actually? yes I'll try redesign patch by Peter's proposal Pavel > > > I don't think it's right to reuse SPIError for this. SPIError is >>> clearly meant to signal an error in the SPI calls. Of

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Is this patch in 'Waiting on Author' state actually? I don't think it's right to reuse SPIError for this. SPIError is clearly meant to signal an error in the SPI calls. Of course, we can't stop users from raising whatever exception they want, but if we're going to advertise

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 11/15/15 11:29 PM, Pavel Stehule wrote: > > > 2015-11-16 5:20 GMT+01:00 Peter Eisentraut >: > > I don't think it's right to reuse SPIError for this. SPIError is > clearly meant to signal an error in the SPI calls. Of course, we can't > stop users from ra

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-16 5:20 GMT+01:00 Peter Eisentraut : > I don't think it's right to reuse SPIError for this. SPIError is > clearly meant to signal an error in the SPI calls. Of course, we can't > stop users from raising whatever exception they want, but if we're going > to advertise that users can raise

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I don't think it's right to reuse SPIError for this. SPIError is clearly meant to signal an error in the SPI calls. Of course, we can't stop users from raising whatever exception they want, but if we're going to advertise that users can raise exceptions, then we should create separate exception c

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-09 19:21 GMT+01:00 Catalin Iacob : > On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule > wrote: > > merged your patch > > So, I just that tested version 08 is the same as the previous patch + > my change and I already tested that on Python 2.4, 2.5, 2.6, 2.7 and > 3.5. > > All previous commen

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Mon, Nov 9, 2015 at 6:31 PM, Pavel Stehule wrote: > merged your patch So, I just that tested version 08 is the same as the previous patch + my change and I already tested that on Python 2.4, 2.5, 2.6, 2.7 and 3.5. All previous comments addressed so I'll mark this Ready for Committer. Thanks

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-09 16:46 GMT+01:00 Catalin Iacob : > On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule > wrote: > > I needed to understand the support for Python 3.5. > > > > The patch with the fix is attached regress tests 3.5 Python > > I wanted to type a reply this morning to explain and then I noticed >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Mon, Nov 9, 2015 at 2:58 PM, Pavel Stehule wrote: > I needed to understand the support for Python 3.5. > > The patch with the fix is attached regress tests 3.5 Python I wanted to type a reply this morning to explain and then I noticed there's another file (_0.out) for Python2.4 and older (as e

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-05 7:24 GMT+01:00 Catalin Iacob : > On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule > wrote: > > It helped me lot of, thank you > > Welcome, I learned quite some from the process as well. > > >> > >> > >> There's just the doc part left then. > > > > > > done > > We're almost there but not

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-05 7:24 GMT+01:00 Catalin Iacob : > On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule > wrote: > > It helped me lot of, thank you > > Welcome, I learned quite some from the process as well. > > >> > >> > >> There's just the doc part left then. > > > > > > done > > We're almost there but not

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule wrote: > It helped me lot of, thank you Welcome, I learned quite some from the process as well. >> >> >> There's just the doc part left then. > > > done We're almost there but not quite. There's still a typo in the docs: excation. A plpy.SPIError

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-11-04 7:06 GMT+01:00 Catalin Iacob : > Sorry, you're right, I didn't notice the x = plpy.SPIError() test. > > I did notice that you included the kw != NULL, I was explaining why it > really is needed even though it *seems* the code also works without > it. > It helped me lot of, thank yo

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Sorry, you're right, I didn't notice the x = plpy.SPIError() test. I did notice that you included the kw != NULL, I was explaining why it really is needed even though it *seems* the code also works without it. There's just the doc part left then. -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-03 17:13 GMT+01:00 Catalin Iacob : > On Tue, Nov 3, 2015 at 12:49 PM, Pavel Stehule > wrote: > >> 1. in PLy_spi_error__init__ you need to check kw for NULL before doing > >> PyDict_Size(kw) otherwise for plpy.SPIError() you get Bad internal > >> call because PyDict_Size expects a real dic

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Nov 3, 2015 at 12:49 PM, Pavel Stehule wrote: >> 1. in PLy_spi_error__init__ you need to check kw for NULL before doing >> PyDict_Size(kw) otherwise for plpy.SPIError() you get Bad internal >> call because PyDict_Size expects a real dictionary not NULL > > > PyDict_Size returns -1 when the

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-02 17:01 GMT+01:00 Catalin Iacob : > Hello, > > Here's a detailed review: > > 1. in PLy_spi_error__init__ you need to check kw for NULL before doing > PyDict_Size(kw) otherwise for plpy.SPIError() you get Bad internal > call because PyDict_Size expects a real dictionary not NULL > PyDict_

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hello, Here's a detailed review: 1. in PLy_spi_error__init__ you need to check kw for NULL before doing PyDict_Size(kw) otherwise for plpy.SPIError() you get Bad internal call because PyDict_Size expects a real dictionary not NULL 2. a test with just plpy.SPIError() is still missing, this would

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-10-28 7:25 GMT+01:00 Catalin Iacob : > On Tue, Oct 27, 2015 at 9:34 AM, Pavel Stehule > wrote: > > Hi > > > > 2015-10-23 7:34 GMT+02:00 Catalin Iacob : > >> The current code doesn't build on Python3 because the 3rd argument of > >> PyMethod_New, the troubled one you need set to NULL has been

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Oct 27, 2015 at 9:34 AM, Pavel Stehule wrote: > Hi > > 2015-10-23 7:34 GMT+02:00 Catalin Iacob : >> The current code doesn't build on Python3 because the 3rd argument of >> PyMethod_New, the troubled one you need set to NULL has been removed. >> This has to do with the distinction between

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-10-23 7:34 GMT+02:00 Catalin Iacob : > On Sat, Oct 17, 2015 at 8:18 PM, Pavel Stehule > wrote: > > here is new patch > > > > cleaned, all unwanted artefacts removed. I am not sure if used way for > > method registration is 100% valid, but I didn't find any related > > documentation. > >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Sat, Oct 17, 2015 at 8:18 PM, Pavel Stehule wrote: > here is new patch > > cleaned, all unwanted artefacts removed. I am not sure if used way for > method registration is 100% valid, but I didn't find any related > documentation. Pavel, some notes about the patch, not a full review (yet?). In

Re: [HACKERS] proposal: PL/Pythonu - function ereport

but the implementation is pretty ugly :( - I didn't write C extensions for > Python before, and the extending exception class with some methods isn't > well supported and well documented. > here is new patch cleaned, all unwanted artefacts removed. I am not sure if used way for method registratio

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-10-16 8:12 GMT+02:00 Craig Ringer : > On 16 October 2015 at 02:47, Pavel Stehule > wrote: > > > postgres=# do $$ > > x = plpy.SPIError('Nazdarek'); > > x.spidata = (100, "Some detail", "some hint", None, None); > > raise x; > > $$ language plpythonu; > > Shouldn't that look more like > > ra

  1   2   >