On Fri, Sep 29, 2017 at 3:06 PM, Peter Eisentraut
wrote:
> On 9/22/17 15:31, Peter Eisentraut wrote:
>> I suggest you create a patch that focuses on the --create part.
>>
>> You can create a separate follow-on patch for the --start part if you
>> wish, but I think that that patch would be rejected
On Thu, Sep 7, 2017 at 8:07 PM, Tom Lane wrote:
> I've pushed up an attempt at this:
>
>
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b976499480bdbab6d69a11e47991febe53865adc
>
> Feel free to suggest improvements.
Thank you, this helps a lot. Especially since some of the beh
On Mon, Sep 4, 2017 at 4:15 PM, Tom Lane wrote:
> Also, the main thing that we need xact.c's involvement for in the first
> place is the fact that implicit transaction blocks, unlike regular ones,
> auto-cancel on an error, leaving you outside a block not inside a failed
> one. So I don't exactly
On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra
wrote:
> Over the past couple of days I've been doing a bit of benchmarking for the
> "group clog" patch [1], and I've ran into what I suspect might be a fairly
> serious performance regression on newer kernels (essentially 4.3.0 and
> newer). I got to
On Tue, Nov 22, 2016 at 8:38 AM, Tsunakawa, Takayuki
wrote:
> transaction_read_only=on does not mean the standby. As the manual article on
> hot standby says, they are different.
> I'm afraid that if the current patch is committed, you will lose interest in
> the ideal solution.
I agree with
On Wed, Nov 16, 2016 at 2:50 PM, Robert Haas wrote:
> Hmm, let's go back to the JDBC method, then. "show
> transaction_read_only" will return true on a standby, but presumably
> also on any other non-writable node. You could even force it to be
> true artificially if you wanted to force traffic
On Tue, Nov 15, 2016 at 3:42 PM, Alvaro Herrera
wrote:
> FWIW I'm not sure "primary" is the right term here either. I think what
> we really want to know is whether the node can accept writes; maybe
> "pg_is_writable_node".
This made me think of another complication: what about cascading
replica
On Tue, Nov 15, 2016 at 5:58 PM, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 9:42 AM, Alvaro Herrera
> wrote:
>> I would rather come up with something that works in both cases that we
>> can extend internally later, say pg_is_primary_node() or something like
>> that instead; and we implement it
On 5/9/16, Stephen Frost wrote:
>> And what if the tests are buggy? New test suites should go through a
>> CF first I think for proper review. And this is clearly one.
>
> They still won't result in data loss, corruption, or other direct impact
> on our users, even if they are buggy. They also wo
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)
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
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
On Sat, Feb 20, 2016 at 2:00 PM, Filip Rembiałkowski
wrote:
> I was stuck because both syntaxes have their ugliness. NOTIFY allows the
> payload to be NULL:
> NOTIFY chan01;
>
> How would this look like in "never" mode?
> NOTIFY chan01, NULL, 'never'; -- seems very cryptic.
The docs say:
"The inf
On 2/9/16, Tom Lane wrote:
> FWIW, I think it would be a good thing if the NOTIFY statement syntax were
> not remarkably different from the syntax used in the pg_notify() function
> call. To do otherwise would certainly be confusing. So on the whole
> I'd go with the "NOTIFY channel [ , payload
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
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
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
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 tes
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
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
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.
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
>>
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
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
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 afte
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
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
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
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
On Wed, Jan 6, 2016 at 3:11 AM, Jim Nasby wrote:
> Which doesn't help anyone, because neither of those provide a list of "hey,
> here's stuff you could do to contribute". The closest we come to that is the
> TODO, which isn't well known and has almost no items for newbies (and the
> newbie items t
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
On Fri, Dec 4, 2015 at 3:47 PM, Robert Haas wrote:
> For the most part, the cleanups in this version are just cosmetic: I
> fixed some whitespace damage, and reverted some needless changes to
> the psql references page that were whitespace-only adjustments. In a
> few places, I tweaked documentat
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
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.
On Tue, Dec 1, 2015 at 1:53 PM, Michael Paquier
wrote:
> Attached is a patch implementing those suggestions. This simplifies
> the code without changing its usefulness. If you are fine with those
> changes I will switch this patch as ready for committer.
I tested the v07 patch (so not Michael's v
On Wed, Nov 18, 2015 at 5:49 PM, Catalin Iacob wrote:
> On Tue, Nov 17, 2015 at 10:13 PM, Tom Lane wrote:
>> 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility,
>> but very easy to explain and very easy to work around.
>>
>> 2. You can have
On Tue, Nov 17, 2015 at 10:13 PM, Tom Lane wrote:
> 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility,
> but very easy to explain and very easy to work around.
>
> 2. You can have multiple -c and/or -f. Each -c is processed in
> the traditional way, ie, either it's a single
On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan wrote:
> I suggest you review the original thread on this subject before a line was
> ever written. "multiple" (see subject line on this whole thread) is clearly
> what is being asked for. Making people turn that into a single argument is
> not what
On Sun, Nov 15, 2015 at 1:27 AM, Andrew Dunstan wrote:
> That seems to me to get rid of the main motivation for this change, which is
> to allow multiple such arguments, which together would as as if they were
> all written to a file which was then invoked like -f file.
It seems to me the motivat
So I promised I'd try to document this. I had a look at the proposed
semantics of -C and I think in the patch they're too complicated which
makes explaining them hard.
My assumptions about behaviour without this patch, from reading the
docs and some experimenting, correct me if I'm wrong:
1. psql
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
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
On Thu, Nov 5, 2015 at 5:27 PM, Robert Haas wrote:
>> I wrote some text. But needs some work of native speaker.
>
> It does. It would be nice if some kind reviewer could help volunteer
> to clean that up.
I'll give it a go sometime next week.
--
Sent via pgsql-hackers mailing list (pgsql-hack
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
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
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
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
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
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
On Mon, Aug 31, 2015 at 4:48 PM, Tom Lane wrote:
> Right now, you might well care about whether a feature arrived in 9.3 vs
> 9.4, for instance; but it's highly unlikely that you care whether a
> feature arrived in 7.1 or 7.2. The problem with this proposal is that
> it will add far more bloat of
On Mon, May 18, 2015 at 9:03 PM Andrew Dunstan wrote:
> So you're arguing that we shouldn't call the operation in question ||
> because it's pretty much the same, mutatis mutandis, as the hstore
> operation of the same name. You've lost me.
>
Hopefully this helps. Peter's argument, as I understa
51 matches
Mail list logo
