On 13/06/11 06:38, Greg Smith wrote:
> On 06/11/2011 03:21 PM, Jeff Janes wrote:
>> I wouldn't expect IPC chatter to show up in profiling, because it
>> costs wall time, but not CPU time. The time spent might be attributed
>> to the kernel, or to pgbench, or to nothing at all.
>>
>
> Profiler
On 01/05/11 21:16, Joshua Berkus wrote:
> Speaking of which, what happened to replacing GEQO with Simulated Annealing?
> Where did that project go?
It stayed on github (https://github.com/wulczer/saio) and stagnated a
bit after I got my degree. It's on the top of my list of things to pick
up aft
On 08/04/11 00:25, Robert Haas wrote:
> On Thu, Apr 7, 2011 at 5:06 PM, Jan Urbański wrote:
>> On 07/04/11 23:01, Robert Haas wrote:
>>> On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
>>>> Add traceback information to PL/Python errors
>>>>
>
On 07/04/11 23:01, Robert Haas wrote:
> On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
>> Add traceback information to PL/Python errors
>>
>> This mimics the traceback information the Python interpreter prints
>> with exceptions.
>>
>> Jan Urba
On 06/04/11 22:16, Jan Urbański wrote:
> On 06/04/11 21:38, Peter Eisentraut wrote:
>> On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
>>> I finally got around to updating the PL/Python tracebacks patch. The
>>> other day I was writing some very simple PL/
On 06/04/11 21:38, Peter Eisentraut wrote:
> On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
>> I finally got around to updating the PL/Python tracebacks patch. The
>> other day I was writing some very simple PL/Python code and the lack of
>> tracebacks is extremely ann
On 31/03/11 07:35, Heikki Linnakangas wrote:
> On 30.03.2011 21:21, Jan Urbański wrote:
>> Valgrind showed me the way. PFA a trivial patch to avoid leaking a
>> PLyProcedure struct in inline blocks.
>
> Hmm, any reason the PLyProcedure struct needs to be allocated in
>
On 28/03/11 17:25, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 28/03/11 04:31, Tom Lane wrote:
>>>> Do the other PLs we ship need similar fixes?
>>>
>>> Offhand I think the other PLs leave management of prepared plans to the
&
On 28/03/11 04:31, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Mar 27, 2011 at 04:51:13PM +, Tom Lane wrote:
>>> Fix plpgsql to release SPI plans when a function or DO block is freed.
>
>> Do the other PLs we ship need similar fixes?
>
> Offhand I think the other PLs leave management o
Hi,
I just wanted to thank everyone involved in shepherding the PL/Python
patches into the master repo, the testers, reviewers, commenters and
especially Peter, for their help and diligence.
The outstanding tracebacks patch is still being worked on, but
irrelevant of whether it will make it or no
On 07/03/11 22:55, Peter Eisentraut wrote:
> On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote:
>> On 07/03/11 14:01, Jan Urbański wrote:
>>> On 07/03/11 13:53, Peter Eisentraut wrote:
>>>> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
>>>>
On 07/03/11 14:01, Jan Urbański wrote:
> On 07/03/11 13:53, Peter Eisentraut wrote:
>> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
>>> But fixing "raise plpy.Fatal()"
>>> to actually cause a FATAL is something that should be extracted from
>>&
On 07/03/11 13:53, Peter Eisentraut wrote:
> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
>> But fixing "raise plpy.Fatal()"
>> to actually cause a FATAL is something that should be extracted from
>> this patch and committed, even if the full patch does
On 07/03/11 13:53, Peter Eisentraut wrote:
> On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote:
>> I did some tests with the attached test script, calling various of the
>> functions defined there and the error messages more or less made sense
>> (or at least were
On 02/03/11 22:28, Jan Urbański wrote:
> On 01/03/11 22:12, Peter Eisentraut wrote:
>> On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote:
>>> So you end up with a context message saying "PL/Python function %s"
>>> and a detail message with the sav
On 05/03/11 01:58, Tom Lane wrote:
> So while hacking away at the PLs-as-extension changes I ran across an
> unforeseen complication. plperl and plpython use the same C function
> entry points for both their trusted and untrusted variants. This is
> problematic for making them into extensions, si
On 02/03/11 16:28, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 02/03/11 14:25, Robert Haas wrote:
>>> But does bumping the ref count then create a leak the rest of the time?
>
>> Not really, because you never want to garbage collect the spiexceptions
>> module (just like you
On 02/03/11 14:25, Robert Haas wrote:
> On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wrote:
>>> That seems to have fixed it, so I have applied the patch. Would you like
>>> to supply some comments to got with it?
>>
>> The comment would be something like
>
On 02/03/11 01:05, Andrew Dunstan wrote:
>
>
> On 03/01/2011 05:19 PM, Jan Urbański wrote:
>> On 01/03/11 22:07, Andrew Dunstan wrote:
>>>
>>> On 03/01/2011 03:53 PM, Jan Urbański wrote:
>>>> On 01/03/11 21:35, Tom Lane wrote:
>>>>> J
On 01/03/11 22:07, Andrew Dunstan wrote:
>
>
> On 03/01/2011 03:53 PM, Jan Urbański wrote:
>> On 01/03/11 21:35, Tom Lane wrote:
>>> Josh Berkus writes:
>>>> I'm ok with closing things as of the end of the 15 days, say
>>>> Thursday or
>&
On 01/03/11 21:35, Tom Lane wrote:
> Josh Berkus writes:
>> I'm ok with closing things as of the end of the 15 days, say Thursday or
>> Friday.
>
> It might be a good idea to make a list of what we have left to do before
> we can wrap an alpha. Here are some things on my list. Not all of them
>
On 01/03/11 20:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Currently the traceback is added to the detail and the original
>> errdetail is preserved. So you'd get the detail line and the traceback
>> below it.
>
> Hm? I'm talking about plpython_error_callback() and friends,
On 01/03/11 20:15, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> After thinking about it more I believe that the context field should
>> keep on being a one line indication of which function the message comes
>> from (and that's how it's done in PL/pgSQL for instance), and the deta
On 28/02/11 19:38, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote:
>>> I'm seeing a core dump as well as multiple inconsistencies in error
>>> message spelling in the plpython regression tests on a Fedora 13 box
>>> (python 2.6.4). Several buildfar
On 26/02/11 16:10, Peter Eisentraut wrote:
> On lör, 2011-02-26 at 09:34 +0100, Jan Urbański wrote:
>> - Original message -
>>> On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański
>>> wrote:
>>>> On 24/02/11 14:10, Peter Eisentraut wrote:
>>>&g
> > > On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański
> > > wrote:
> > > > On 15/02/11 20:39, Peter Eisentraut wrote:
> > > > > On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
> > > > > > [a bug that we don't know how to
- Original message -
> On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański
> wrote:
> > On 15/02/11 20:39, Peter Eisentraut wrote:
> > > On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
> > > > [a bug that we don't know how to fix]
> From this d
- Original message -
> On Wed, Feb 9, 2011 at 5:22 PM, Peter Eisentraut wrote:
> > On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
> > > The documentation could probably still use more word-smithing but
> > > that can happen later. I'm marking this as ready for a committer.
> >
>
- Original message -
> On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański
> wrote:
> > On 24/02/11 14:10, Peter Eisentraut wrote:
> > Hm, perhaps, I put it in the details, because it sounded like the place
> > to put information that is not that important, but still h
On 24/02/11 14:10, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
>> For errors originating from Python exceptions add the traceback as the
>> message detail. The patch tries to mimick Python's traceback.py module
>> behaviour as c
On 22/02/11 22:48, Peter Eisentraut wrote:
> Committed this, with two changes: Changed some things around with the
> way const char * is propagated. Just casting it away is not nice. Also
> dropped the error tests in the _quote.sql regression test. This
> generates three different wordings of e
On 15/02/11 20:39, Peter Eisentraut wrote:
> On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
>> Because the invocation that actually recurses sets up the scene for
>> failure.
>
> That's what we're observing, but I can't figure out why it is. If you
- Original message -
> On mån, 2011-02-14 at 22:22 +0100, Jan Urbański wrote:
> > The problem is that every *second* call to the function fails,
> > regardless of the number. The first execution succeeds, but then
> > PLy_delete_args deletes the argument from the
On 14/02/11 22:13, Jan Urbański wrote:
> On 14/02/11 21:06, Peter Eisentraut wrote:
>> On ons, 2011-02-09 at 10:02 +0100, Jan Urbański wrote:
>>> On 09/02/11 04:52, Hitoshi Harada wrote:
>>>> 2010/12/31 Jan Urbański :
>>>>> (continuing the flurry of p
On 14/02/11 21:06, Peter Eisentraut wrote:
> On ons, 2011-02-09 at 10:02 +0100, Jan Urbański wrote:
>> On 09/02/11 04:52, Hitoshi Harada wrote:
>>> 2010/12/31 Jan Urbański :
>>>> (continuing the flurry of patches)
>>>>
>>>> Here'
On 11/02/11 10:53, Jan Urbański wrote:
> On 10/02/11 22:26, Steve Singer wrote:
Here's an updated patch with documentation. It's an incremental patch on
top of the latest explicit-subxacts version.
Cheers,
Jan
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
On 11/02/11 17:22, Steve Singer wrote:
> On 11-02-10 05:20 AM, Jan Urbański wrote:
>>
>> D'oh, I was thinking about whether it's safe to skip the internal
>> subxact if you're in an implicit one and somehow I always convinced
>> myself that since yo
On 12/02/11 10:00, Alex Hunsaker wrote:
> On Sat, Feb 12, 2011 at 01:50, Jan Urbański wrote:
>> On 12/02/11 04:12, Alex Hunsaker wrote:
>>> In PLy_traceback fname and prname look like they will leak (well as
>>> much as a palloc() in an error path can leak I sup
On 12/02/11 04:12, Alex Hunsaker wrote:
> On Wed, Feb 9, 2011 at 02:10, Jan Urbański wrote:
>> On 06/02/11 20:12, Jan Urbański wrote:
>>> On 27/01/11 22:58, Jan Urbański wrote:
>>>> On 23/12/10 14:56, Jan Urbański wrote:
>>>>> Here's a patch impl
On 11/02/11 16:47, Robert Haas wrote:
> On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
>> On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
>> It seems a bit heavy handed to invalidate and remake the entire
>> plpython function whenever we hit this case. I think we c
On 11/02/11 16:43, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wrote:
>>> That's it for now. It is an exciting feature and plpython will be the
>>> first language to think of when you're building "object database" if
>>&g
On 10/02/11 22:26, Steve Singer wrote:
> On 11-02-10 03:13 PM, Jan Urbański wrote:
>> On 10/02/11 20:24, Peter Eisentraut wrote:
>
> Here is the rest of my review.
Thanks!
> Ideally char * members of ExceptionMap would be const, but since many
> versions of python take
On 10/02/11 20:24, Peter Eisentraut wrote:
> On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote:
>> On 27/01/11 23:24, Jan Urbański wrote:
>>> On 11/01/11 12:20, Jan Urbański wrote:
>>>> On 11/01/11 01:27, Tom Lane wrote:
>>>>> Hannu Krosing wr
On 10/02/11 01:26, Steve Singer wrote:
> On 11-02-09 05:22 PM, Peter Eisentraut wrote:
>> On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
>> Is it necessarily a good idea that an explicit subtransaction disables
>> the implicit sub-subtransactions? It might be conceivable that you'd
>> stil
On 06/02/11 20:12, Jan Urbański wrote:
> On 27/01/11 22:58, Jan Urbański wrote:
>> On 23/12/10 14:56, Jan Urbański wrote:
>>> Here's a patch implementing traceback support for PL/Python mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01
On 27/01/11 22:42, Jan Urbański wrote:
> On 23/12/10 14:50, Jan Urbański wrote:
>> Here's a patch implementing properly invalidating functions that have
>> composite type arguments after the type changes, as mentioned in
>> http://archives.postgresql.org/pgsql-hackers/
On 09/02/11 04:52, Hitoshi Harada wrote:
> 2010/12/31 Jan Urbański :
>> (continuing the flurry of patches)
>>
>> Here's a patch that stops PL/Python from removing the function's
>> arguments from its globals dict after calling it. It's
>> an increme
On 07/02/11 06:10, Hitoshi Harada wrote:
> 2011/2/7 Jan Urbański :
>> On 04/02/11 16:26, Hitoshi Harada wrote:
>>> 2011/1/28 Jan Urbański :
>>>> On 27/01/11 00:41, Jan Urbański wrote:
>>>>> I'm also attaching an updated version that should a
On 08/02/11 15:44, Hitoshi Harada wrote:
> 2011/2/8 Steve Singer :
>> On 11-02-07 10:37 PM, Robert Haas wrote:
>>
>>> - The PL/python extravaganza. I'm not really clear where we stand
>>> with this. There are a lot of patches here.
>>>
>>
>> Some of the patches have been committed a few others ar
On 27/01/11 23:24, Jan Urbański wrote:
> On 11/01/11 12:20, Jan Urbański wrote:
>> On 11/01/11 01:27, Tom Lane wrote:
>>> Hannu Krosing writes:
>>>> On 10.1.2011 17:20, Jan Urbański wrote:
>>>>> I changed that patch to use Perl instead of sed to gen
On 27/01/11 22:58, Jan Urbański wrote:
> On 23/12/10 14:56, Jan Urbański wrote:
>> Here's a patch implementing traceback support for PL/Python mentioned in
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>> an incremental patch on top of t
On 06/02/11 10:54, Jan Urbański wrote:
> On 04/02/11 18:10, Hitoshi Harada wrote:
>> 2011/1/11 Jan Urbański :
>>> Here's a patch that adds a few PL/Python functions for quoting strings.
>>> It's an incremental patch on top of the plpython-refactor patch sent
On 04/02/11 17:19, Hitoshi Harada wrote:
> 2011/1/28 Jan Urbański :
>> On 23/12/10 15:15, Jan Urbański wrote:
>>> Here's a patch implementing custom parsers for data types mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It'
On 02/02/11 14:16, Steve Singer wrote:
> On 11-01-27 05:11 PM, Jan Urbański wrote:
>> On 23/12/10 15:32, Jan Urbański wrote:
>>> Here's a patch implementing explicitly starting subtransactions
>>> mentioned in
>>> http://archives.postgresql.org/pgsql-
On 04/02/11 16:26, Hitoshi Harada wrote:
> 2011/1/28 Jan Urbański :
>> On 27/01/11 00:41, Jan Urbański wrote:
>>> I'm also attaching an updated version that should apply on top of my
>>> github refactor branch (or incrementally over the new set of refactor
>>
On 04/02/11 18:10, Hitoshi Harada wrote:
> 2011/1/11 Jan Urbański :
>> Here's a patch that adds a few PL/Python functions for quoting strings.
>> It's an incremental patch on top of the plpython-refactor patch sent in
>> http://archives.postgresql.org/message-
On 02/02/11 14:16, Steve Singer wrote:
> On 11-01-27 05:11 PM, Jan Urbański wrote:
>> On 23/12/10 15:32, Jan Urbański wrote:
>>> Here's a patch implementing explicitly starting subtransactions
>>> mentioned in
>>> http://archives.postgresql.org/pgsql-
On 31/01/11 00:03, Jan Urbański wrote:
> On 29/01/11 22:13, Jan Urbański wrote:
>> On 29/01/11 22:10, Steve Singer wrote:
>>> On 11-01-29 03:39 PM, Jan Urbański wrote:
>>>>
>>>> D'oh, you're right, thanks. Attached patch with fix. Curiosly, rig
On 29/01/11 22:13, Jan Urbański wrote:
> On 29/01/11 22:10, Steve Singer wrote:
>> On 11-01-29 03:39 PM, Jan Urbański wrote:
>>>
>>> D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
>>> in master your example with plpy.prepare
On 30/01/11 23:08, Robert Haas wrote:
> On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wrote:
>> On 12/01/11 19:57, Jan Urbański wrote:
>>> On 11/01/11 21:21, Jan Urbański wrote:
>>>> On 11/01/11 18:59, Tom Lane wrote:
>>>>> =?UTF-8?B?SmFuIFVyYmHFhHNr
On 30/01/11 23:04, Jan Urbański wrote:
> On 30/01/11 23:02, Alexander Korotkov wrote:
>> Hi!
>>
>> On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański > <mailto:wulc...@wulczer.org>> wrote:
>>
>> I saw that the code tries to handle ILIKE searches,
On 30/01/11 23:02, Alexander Korotkov wrote:
> Hi!
>
> On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański <mailto:wulc...@wulczer.org>> wrote:
>
> I saw that the code tries to handle ILIKE searches, but apparently it's
> failing somewhere.
>
> It was j
On 29/01/11 13:07, Alexander Korotkov wrote:
> Hello!
Hi!
>
> New version of patch is in the attachment. Some comments was added in
> this version. Likely these comments need significant correction because
> of my english.
Ooh, ok, the comments now helped me understand what's exactly going on
i
On 29/01/11 22:10, Steve Singer wrote:
> On 11-01-29 03:39 PM, Jan Urbański wrote:
>>
>> D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
>> in master your example with plpy.prepare will result in "savepoint"
>> being swallo
On 29/01/11 21:27, Steve Singer wrote:
> On 11-01-27 04:33 PM, Jan Urbański wrote:
>>> I am finding the treatment of savepoints very strange.
>>> If as a function author I'm able to recover from errors then I'd expect
>>> (or maybe want) to be able to mana
On 11/01/11 12:20, Jan Urbański wrote:
> On 11/01/11 01:27, Tom Lane wrote:
>> Hannu Krosing writes:
>>> On 10.1.2011 17:20, Jan Urbański wrote:
>>>> I changed that patch to use Perl instead of sed to generate the
>>>> exceptions, which should be a more
On 23/12/10 15:32, Jan Urbański wrote:
> Here's a patch implementing explicitly starting subtransactions mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the spi-in-subxacts patch sent eariler.
Updated to
On 23/12/10 15:15, Jan Urbański wrote:
> Here's a patch implementing custom parsers for data types mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to m
On 23/12/10 14:56, Jan Urbański wrote:
> Here's a patch implementing traceback support for PL/Python mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to m
On 23/12/10 14:50, Jan Urbański wrote:
> Here's a patch implementing properly invalidating functions that have
> composite type arguments after the type changes, as mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch
On 19/01/11 02:16, Hitoshi Harada wrote:
> Thanks. I tested the new version and looks ok. I'll mark it "Ready for
> Commiter".
Updated version against master.
Jan
diff --git a/src/include/catalog/pg_pltemplate.h b/src/include/catalog/pg_pltemplate.h
index d987ddc..c0578f9 100644
*** a/src/include
On 27/01/11 00:41, Jan Urbański wrote:
> I'm also attaching an updated version that should apply on top of my
> github refactor branch (or incrementally over the new set of refactor
> patches that I will post shortly to the refactor thread).
Attached is a patch for master, as th
On 26/01/11 04:51, Steve Singer wrote:
> On 10-12-23 08:45 AM, Jan Urbański wrote:
> I see you've merged the changes from the refactoring branch down but
> haven't yet posted an updated patch. This review is based on
> 2f2b4a33bf344058620a5c684d1f2459e505c727
Thanks for the
On 27/01/11 00:40, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
> Everything(*) i
On 24/01/11 05:42, Hitoshi Harada wrote:
> 2011/1/23 Jan Urbański :
>> On 22/01/11 11:15, Hitoshi Harada wrote:
> I tested the new incremental patch and the previous example works
> fine. I don't know if this can be handled properly but another example
> is:
>
> regre
On 27/01/11 00:15, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2011-01-26 at 17:47 -0500, Tom Lane wrote:
>>> I was a bit disturbed by the fact that fixing only one of the four
>>> variant files was enough to turn the whole buildfarm green. Are the
>>> other three cases even needed anym
, like
create function noname_concat(text, text) returns text language
plpythonu as $$
return args[0] + args[1]
$$;
Perhaps we should throw an error if you try to define a function with an
explicit "args" variable? It'd be a backwards-compatibility problem, but
then again these
Hi,
I tested the patch from
http://archives.postgresql.org/message-id/aanlktikvxx6_ajzb52ona7mbzijcpdqszomcd-3u1...@mail.gmail.com
which adds GIN and GIST index support for wildcard LIKE queries using
pg_trgm.
The patch is a context diff that applies cleanly. Regression test work
after applying i
On 22/01/11 19:38, Tom Lane wrote:
> Buildfarm members bobcat (Fedora 14 x86) and frogmouth (mingw) have
> been showing an assertion failure in the plpython regression tests
> since this patch went in:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=740e54c
> Given these facts,
On 22/01/11 21:53, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
>> Refactor PLy
On 22/01/11 11:15, Hitoshi Harada wrote:
> This is a review for
> https://commitfest.postgresql.org/action/patch_view?id=460
Thanks,
> One issue is typmod of record type.
>
> regression=# create or replace function func1(t text) returns record
> as $$ return {'name': t, 'value': 0} $$ language
On 20/01/11 01:26, Jan Urbański wrote:
> On 19/01/11 10:57, Jan Urbański wrote:
>> On 18/01/11 23:22, Peter Eisentraut wrote:
>>> #2: It looks like this loses some information/formatting in the error
>>> message. Should we keep the pointing arrow there?
>
>
On 19/01/11 10:57, Jan Urbański wrote:
> On 18/01/11 23:22, Peter Eisentraut wrote:
>> #2: It looks like this loses some information/formatting in the error
>> message. Should we keep the pointing arrow there?
>> CONTEXT: PL/Python function "sql_syntax_error"
On 19/01/11 16:35, David Fetter wrote:
> On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
>> On 19/01/11 02:06, Hitoshi Harada wrote:
>>> - PLy_(input|output)_tuple_funcs() in PLy_trigger_handler() is added.
>>> The comment says it should check f
On 19/01/11 02:06, Hitoshi Harada wrote:
> 2011/1/19 Peter Eisentraut :
>> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>>>> Here they are. There are 16 patches in total. They amount to what&#
On 18/01/11 23:22, Peter Eisentraut wrote:
> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>>> Here they are. There are 16 patches in total. They amount to what's
>>> currently in my refactor
On 17/01/11 09:26, Jan Urbański wrote:
> On 17/01/11 01:02, Hitoshi Harada wrote:
>> This is a review for the patch sent as
>> https://commitfest.postgresql.org/action/patch_view?id=456
>> It includes adequate amount of test. I found regression test failure
>>
On 17/01/11 01:02, Hitoshi Harada wrote:
> This is a review for the patch sent as
> https://commitfest.postgresql.org/action/patch_view?id=456
Thanks!
> It includes adequate amount of test. I found regression test failure
> in plpython_error.
> My environment is CentOS release 5.4 (Final) with p
Hi,
what follows is a review of the FDW API patch from
http://archives.postgresql.org/message-id/20110114212358.82c7.69899...@metrosystems.co.jp
All three patches apply cleanly and compile without warnings. Regression
tests pass.
Let me go patch by patch, starting with the first one that adds th
On 08/01/11 23:37, Alexander Korotkov wrote:
> I updated my patch to make it use full index scan in GIN index which is
> possible thanks to recent Tom Lane patch. Now wildcard, where no trigram can
> be extracted from, invokes full index scan, which is slow but correct.
Hi,
unfortunately, this ch
On 11/01/11 18:59, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 11/01/11 17:11, Tom Lane wrote:
>>> Huh? Why in the world would the specific location of the #include have
>>> anything to do with the problem?
>
>> I'v having a hard time convincing make to generate errcodes.h b
On 11/01/11 17:11, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> I tried wiring it into the build system, but failed, I can't figure out
>>> which Makefiles should be updated in order to make errcodes.h and
>>> plerrcodes.h generated headers. Could someone help with that?
>
>> Tr
On 28/12/10 12:25, Jan Urbański wrote:
> Here's the basic errcodes.txt file and three scripts to generate
> errcodes.h, plerrcodes.h and part of errcodes.sgml.
>
> I tried wiring it into the build system, but failed, I can't figure out
> which Makefiles should be
On 11/01/11 01:27, Tom Lane wrote:
> Hannu Krosing writes:
>> On 10.1.2011 17:20, Jan Urbański wrote:
>>> I changed that patch to use Perl instead of sed to generate the
>>> exceptions, which should be a more portable.
>
>> Why not python ?
>
> Because
Here's a patch that adds a few PL/Python functions for quoting strings.
It's an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/functions
The
On 23/12/10 15:40, Jan Urbański wrote:
> Here's a patch implementing custom Python exceptions for SPI errors
> mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the explicit-subxacts patch sent eariler.
I
On 01/01/11 01:00, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
>> It does some architectural changes to PL/Python that make it easier to
>> implement other features, like for instance a validator function. The
>> full list of changes in
(continuing the flurry of patches)
Here's a patch that stops PL/Python from removing the function's
arguments from its globals dict after calling it. It's
an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
Git
On 26/12/10 21:33, Jan Urbański wrote:
> On 26/12/10 21:17, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> Makes sense. Wait, no, errcodes.sgml includes the entries for success
>>> and warnings, but the plpgsql conditions list does not. So we ne
On 26/12/10 21:17, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Makes sense. Wait, no, errcodes.sgml includes the entries for success
>> and warnings, but the plpgsql conditions list does not. So we need a
>> separate column to differentiate.
>
> OK. But not 0/1 please. Maybe '
101 - 200 of 348 matches
Mail list logo
