When you try to use the NEW variable in a statement-level trigger, you get
ERROR: record "new" is not assigned yet
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
which is not too friendly, given that people sometimes forget to specify
FOR EACH at all, get the defaul
Consider this:
create table arrays as select array[random(), random(), random(),
random(), random(), random()] as a from generate_series(1, 100);
create or replace function plpython_outputfunc() returns void as $$
c = plpy.cursor('select a from arrays')
for row in c:
pass
$$ language plpy
While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL
and I think there are places where memory is not freed sufficiently early.
Attached are two functions that when run will make the backend's memory
consumption increase until they finish. With both, the cause is
convert_value_to
On 12/02/12 00:48, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> This is annoying for functions that plough through large tables, doing
>> some calculation. Attached is a patch that does the conversion of
>> PostgreSQL Datums into Python dict objects in a scratch memory context
>>
On 18/02/12 20:30, Tom Lane wrote:
> Dave Malcolm at Red Hat has been working on a static code analysis tool
> for Python-related C code. He reports here on some preliminary results
> for plpython.c:
> https://bugzilla.redhat.com/show_bug.cgi?id=795011
>
> I'm not enough of a Python hacker to eva
On 18/02/12 21:17, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 18/02/12 20:30, Tom Lane wrote:
>>> Dave Malcolm at Red Hat has been working on a static code analysis tool
>>> for Python-related C code. He reports here on some preliminary results
>>> for plpython.c:
>>> https:
On 18/02/12 21:18, Jan Urbański wrote:
> On 18/02/12 21:17, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> On 18/02/12 20:30, Tom Lane wrote:
>>>> Dave Malcolm at Red Hat has been working on a static code analysis tool
>>>> for Pytho
On 14/02/12 01:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> It's not very comfortable, but
>> I think PLyDict_FromTuple can be allowed to be non-reentrant.
>
> I think that's pretty short-sighted. Even if it's safe today (which
> I am not 100% convinced of), there are plenty
On 20/02/12 04:29, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> On 18/02/12 21:17, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
h
On 21/02/12 18:05, Peter Eisentraut wrote:
> On sön, 2012-02-19 at 22:29 -0500, Tom Lane wrote:
>> My only comment is whether elog(ERROR) is appropriate, ie, do we
>> consider these to be internal errors that users will never see in
>> practice? If there's a significant risk of the error being thro
On 21/02/12 18:28, Jan Urbański wrote:
> On 21/02/12 18:05, Peter Eisentraut wrote:
>>> it might be better to use ereport, to expose the message
>>> for translation.
>>>
> After giving it some thought some of these elogs could be changed into
> PLy_elogs (which
On 10/04/12 04:20, Tom Lane wrote:
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
I find this code pretty unreadable, though, and know nothing to
speak of abou
On 10/04/12 07:35, Jan Urbański wrote:
On 10/04/12 04:20, Tom Lane wrote:
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
So, I know what's go
On 10/04/12 20:47, Tom Lane wrote:
I wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Now that I understand what's been going on, I'll try to think of a
non-invasive way of fixing that...
ISTM that conversion of a composite value to Python ought to produce a
dict, now that the other directio
On 10/04/12 21:27, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Yes, that would be ideal, even though not backwards-compatible.
Back-patching is out of the question, but do we want to change trigger
functions to receive dictionaries in NEW?
Hm, I was not thinking of this as being
On 28/05/13 14:04, Szymon Guz wrote:
Hi,
I need to store a global pointer for plpython usage. This is a PyObject*
which can be initialized per session I think
Where should I keep such a pointer?
Hi,
you probably could use a global variable, similar to PLy_interp_globals
that's defined in plp
On 26/06/13 10:51, Dimitri Fontaine wrote:
Peter Eisentraut writes:
$ git clone git://git.postgresql.org/git/postgresql.git
Cloning into 'postgresql'...
I can reproduce that here. I don't know why I have those postgres dirs
then, and I'm pretty confused about my round of testing now.
Maybe
On 27/06/13 15:11, Magnus Hagander wrote:
On Thu, Jun 27, 2013 at 2:16 PM, Peter Eisentraut wrote:
On 6/27/13 6:34 AM, Magnus Hagander wrote:
Is there a reason why we have set the min allowed value for port to 1,
not 1024? Given that you can't actually start postgres with a value of
<1024, sho
Peter Eisentraut writes:
> On 2/12/15 7:28 AM, Jan Urbański wrote:
>> For the sake of discussion, here's a patch to prevent stomping on
>> previously-set callbacks, racy as it looks.
>>
>> FWIW, it does fix the Python deadlock and doesn't cause the PHP seg
Peter Eisentraut writes:
> On 4/2/15 4:32 AM, Jan Urbański wrote:
>>
>> Peter Eisentraut writes:
>>> I don't think this patch would actually fix the problem that was
>>> described after the original bug report
>>> (http://www.postgresql.org/mess
Peter Eisentraut writes:
> On 4/3/15 7:44 AM, Jan Urbański wrote:
>> To reiterate: I recognise that not handling the callbacks is not the right
>> answer. But not stomping on callbacks others might have set sounds like a
>> minimal and safe improvement.
>
> I think yo
Peter Eisentraut writes:
> On 2/12/15 7:28 AM, Jan Urbański wrote:
>> +#if OPENSSL_VERSION_NUMBER < 0x1000
>> +/* OpenSSL 1.0.0 deprecates the CRYPTO_set_id_callback function and
>> provides a
>> + * default implementation, so there's no need for our
Though not the original patch autor, I did modify and submit it to the
CF app, so I'll reply here :)
On 10/12/12 19:20, Karl O. Pinc wrote:
On 12/09/2012 10:33:59 PM, Karl O. Pinc wrote:
I've gone ahead and signed up to review this patch.
Thanks!
There were 2 outstanding issue raised:
I
On 12/12/12 20:21, Karl O. Pinc wrote:
There were 2 outstanding issue raised:
Is this useful enough/proceeding in the right direction to commit
now?
Should some of the logic be moved out of a subroutine and into the
calling code?
I can see arguments to be made for both sides. I'm asking
Hi,
Here's a trivial patch that fixes a comment in execProcNode.c
For archeological interest, that comment dates back to when it was
written in POSTQUEL... The cleanup in
a9b1ff4c1d699c8aa615397d47bb3071275c64ef changed RETRIEVE to SELECT, but
forgot to add a FROM clause :)
Cheers,
Jan
diff
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL/Perl does these things I find that one
failed malloc (in compile_plperl_function) thr
On 28/11/10 05:23, Andrew Dunstan wrote:
>
>
> On 11/27/2010 10:28 PM, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> I noticed that PL/Python uses a simple wrapper around malloc that does
>>> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
>>> normally do
Hi,
no, no patch(es) yet. I'm going through plpython.c trying as best I can
to improve things there. I'll have a patch (or patches) ready for the
January commitfest, but I thought I'd open up a discussion already to
spare me having to redo features because the way I attacked the problem
is a dead
On 07/12/10 21:33, Andres Freund wrote:
> On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote:
>> * execute SPI calls in a subtransaction, report errors back to Python
>> as exceptions that can be caught etc.
> Youre doing that unconditionally? I think the performance i
On 07/12/10 23:00, Andrew Dunstan wrote:
> On 12/07/2010 04:50 PM, Peter Eisentraut wrote:
>>
>>> The code is on https://github.com/wulczer/postgres, in the plpython
>>> branch. I'll be rebasing it regularly, so don't be surprised by commit
>>> hashes changing.
>> I think rebasing published reposit
On 08/12/10 18:45, Tom Lane wrote:
> The real fix in my mind is to replace GEQO search with something
> smarter. I wonder what happened to the SA patch that was reported
> on at PGCon.
I got distracted with other things :( I'll try to plan the two queries
with SA and see what the results are. If
On 08/12/10 19:02, Jan Urbański wrote:
> On 08/12/10 18:45, Tom Lane wrote:
>> The real fix in my mind is to replace GEQO search with something
>> smarter. I wonder what happened to the SA patch that was reported
>> on at PGCon.
>
> I got distracted with other things
On 08/12/10 21:18, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I'm pleasantly surprised that the SA code as it stands today, setting
>> the equlibrium factor to 8 and temperature reduction factor to 0.4, the
>> query takes 1799.662 ms in total.
>
> Cool.
>
>> With the default v
It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.
There was talk about including hstore in core, is there still chance for
that to happen in 9.1? I'd li
> Robert Haas writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core. Then
> we can look at it and see exactly what we'd lose from keeping hstore out
On 14/12/10 18:05, David E. Wheeler wrote:
> On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote:
>
>> A function said to be returning a hstore could return a dictionary and if it
>> would have only string keys/values, it would be changed into a hstore (and
>> if not,
On 14/12/10 17:52, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
>>> It would be cool to be able to transparently use hstores as Python
>>> dictionaries and vice versa. It would be easy enough with hstore as a
>
On Wed, Dec 15, 2010 at 12:19:53AM +0100, Jan Urbański wrote:
> Problem: what to do it hstore_plpython gets loaded, but hstore is not
> yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in),
> so loading hstore_plpython without loading hstore will result in an
> e
On 15/12/10 15:38, Tom Lane wrote:
> Jan =?utf-8?B?VXJiYcWEc2tp?= writes:
>> OK, here's another master plan:
>
>> 1) hstore_plplython, when loaded, looks for a type called "hstore". If
> you created a "hstore" type that does not come from hstore.so, and you
> still load hstore_plpython, you deser
On 15/12/10 16:11, Tom Lane wrote:
> Robert Haas writes:
>> I was asking what would satisfy you as regards a reliable way to
>> identify a type, not what you think we should do about this particular
>> proposal.
>
> Okay: a preassigned OID is safe. I haven't seen any other safe
> proposals. Rel
On 15/12/10 16:25, Dmitriy Igrishin wrote:
> 2010/12/15 Jan Urbański
>> So how about just adding a text column to pg_type and a IDENTIFIER
>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it
>> pushing the argument to the extreme? Someone can
Hi,
there seems to be a problem in the way we add exceptions to the plpy
module in PL/Python compiled with Python 3k.
Try this: DO $$ plpy.SPIError $$ language plpython3u;
I'm not a Python 3 expert, but I nicked some code from the Internet and
came up with this patch (passes regression tests on
On 18/12/10 18:56, Jan Urbański wrote:
> I'm not a Python 3 expert, but I nicked some code from the Internet and
> came up with this patch (passes regression tests on both Python 2 and 3).
I tried to be too cute with the regression test, it fails with Python
2.3.7 (the latest
On 08/12/10 22:41, Peter Eisentraut wrote:
> On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote:
>> Peter suggested having a mail/patch per feature and the way I intend
>> to do that is instead of having a dozen branches, have one and after
>> I'm done rebase i
On 23/12/10 12:16, Marti Raudsepp wrote:
> On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote:
>> * providing custom exceptions for SPI errors, so you can catch only
>> UniqueViolations and not have to muck around with SQLCODE
>
> py-postgresql already has a mapping from
Here's a patch implementing a validator functoin 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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/validator.
Cheers,
Jan
On 23/12/10 14:41, Jan Urbański wrote:
> Here's a patch implementing a validator functoin 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.
>
> Git branc
Here's a patch implementing a executing SPI in an subtransaction
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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/spi-in-
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 top of the plpython-refactor patch sent eariler.
Git branch for thi
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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/tracebacks.
Here's a patch implementing table functions 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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/table-functions.
This allow
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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/custom-parsers
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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/explicit-s
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.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/cust
On 26/12/10 05:55, Robert Haas wrote:
> On Sat, Dec 25, 2010 at 3:39 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Add foreign data wrapper error code values for SQL/MED.
>>> Extracted from a much larger patch by Shigeru Hanada.
>>
>> This patch is quite incomplete. Any patch that adds to errco
On 26/12/10 18:17, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Dec 26, 2010 at 8:03 AM, Jan Urbański wrote:
>>> See
>>> https://github.com/wulczer/postgres/commit/44fc42b7708f23483156e4e0e1e321e68b2a7e2d#diff-0
>>> for something that maybe coul
On 26/12/10 20:33, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I then tried to do the same for plerrcodes.h, but found discrepancies.
>
> You shouldn't assume that errcodes.h necessarily includes all the info
> needed to create the other two files.
>
> The way I'd envision this
On 26/12/10 20:57, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> How about a format like this then:
>
>> # Comment
>> Section: Class 2F - SQL Routine Exception
>> macro_name sqlstate plpgsqlname is_error
>
>> That is: # and blank lines are comments, lines starting with "Section:"
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 '
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
(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 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
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
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 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
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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,
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
, 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
On 28/01/13 12:31, Marko Tiikkaja wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff |filterdiff --format=context to re-format the p
On 30/01/13 22:23, Tom Lane wrote:
BTW, I'm also wondering if it's really necessary for plpython/plpy_spi.c
to be looking into spi_priv.h ...
As far as I can tell, it's not necessary, spi.h would be perfectly fine.
Cheers,
Jan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 30/07/12 14:33, Achim Domma wrote:
Hi,
Hi Achim,
this list is meant for discussing the development of PostgreSQL, in the
future you might want to ask your question on pgsql-general.
However, to answer your question:
I call the function like this:
select * from vectormatch(array(select
On 06/08/12 13:59, Heikki Linnakangas wrote:
On 20.07.2012 10:13, Jan Urbański wrote:
On 20/07/12 08:59, Jan Urbański wrote:
On 18/07/12 17:17, Heikki Linnakangas wrote:
On 14.07.2012 17:50, Jan Urbański wrote:
If pg_do_encoding_conversion() throws an error, you don't get a chance
to
On 21/08/12 20:13, Josh Berkus wrote:
No. I get the same backtrace when I try against the 9.1.5 (REL9_1_STABLE)
branch.
I have reproduced this on Linux, seems like the fix is to to run the
postmaster with this env variable exported:
PYTHONHOME=/opt/ActivePython-3.2/
(or wherever you insta
On 22/08/12 13:28, Sachin Srivastava wrote:
Yes, It worked for me also..
So will this be a workaround? Or do we intend to use something like
Py_SetPythonHome() before calling Py_Initialize()/
I think the best we can do is to document that for some installations
you might need to set PYTHONHOME
There's a typo in src/tools/RELEASE_CHANGES
It just ticked off my OCD I guess...
Cheers,
Jan
diff --git a/src/tools/RELEASE_CHANGES b/src/tools/RELEASE_CHANGES
new file mode 100644
index 5f1277a..aba1630
*** a/src/tools/RELEASE_CHANGES
--- b/src/tools/RELEASE_CHANGES
*** Then doing i
On 30/10/12 22:06, Oskari Saarenmaa wrote:
PL/Python maps Python SPIError exceptions with 'spidata' attribute into SQL
errors. PL/Python also creates classes in plpy.spiexceptions for all known
errors but does not initialize their spidata, so when a PL/Python function
raises such an exception it
On 05/11/12 18:35, Robert Haas wrote:
On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański wrote:
On 30/10/12 22:06, Oskari Saarenmaa wrote:
PL/Python maps Python SPIError exceptions with 'spidata' attribute into
SQL
errors.
Here's an alternative patch that takes advantage of the
On 05/11/12 19:07, Jan Urbański wrote:
On 05/11/12 18:35, Robert Haas wrote:
You should probably add this to the next CF so we don't forget about it.
I will, as soon as I recover my community account.
Added as https://commitfest.postgresql.org/action/patch_view?id=971
J
--
Sen
Arie Bikker wrote:
> Hi all,
>
> I've combined the review suggestions of Jan Urbański, Scott Bailey, and
> others.
> This was a lot harder, then I had foreseen; and I took my time to do it
> the right way (hope you agree!).
Hi,
I see the patch has been marked as "Re
On 24/03/10 21:06, Markus Wanner wrote:
Steve,
Steve Singer wrote:
$ git clone http://git.postgres-r.org/dtester
Initialized empty Git repository in
/local/home/ssinger/src/dtester/dtester/.git/
fatal: http://git.postgres-r.org/dtester/info/refs download error -
The requested URL returned error
On 10/04/12 21:47, Jan Urbański wrote:
On 10/04/12 21:27, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Yes, that would be ideal, even though not backwards-compatible.
Back-patching is out of the question, but do we want to change trigger
functions to receive dictionaries in NEW
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Apparently, they changed the C API for doing slicing, or rather made one
of the two APIs for it silently do nothing. Details are difficult to
find, but this email me
On 03/05/12 11:04, Jan Urbański wrote:
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Apparently, they changed the C API for doing slicing, or rather made one
of the two APIs for it silently do nothing. De
On 04/05/12 20:00, Jan Urbański wrote:
On 03/05/12 11:04, Jan Urbański wrote:
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Sounds ugly. I'll take a look.
I found some instructions on how to dea
On 10/05/12 19:45, Peter Eisentraut wrote:
On lör, 2012-05-05 at 22:45 +0200, Jan Urbański wrote:
Apparently once you implement PyMappingMethods.mp_subscript you can
drop PySequenceMethods.sq_slice, but I guess there's no harm in
keeping it (and I'm not sure it'd work on Pytho
On 27/06/12 11:51, Asif Naeem wrote:
Hi,
On Windows 7 64bit, plpython is causing server crash with the following
test case i.e.
CREATE PROCEDURAL LANGUAGE 'plpython3u';
CREATE OR REPLACE FUNCTION pymax (a integer, b integer)
RETURNS integer
AS $$
if a> b:
return a
return b
$$ LA
1 - 100 of 348 matches
Mail list logo
