On 06/02/2015 12:33 PM, Filipe Pina wrote:
Basically, in an (maybe-over)simplified example:
CREATE OR REPLACE FUNCTION add_transaction(transaction core_transaction)
RETURNS integer AS $$
DECLARE
transaction2 core_transaction;
BEGIN
transaction.field1 := 'lapse’;
transaction2.
Basically, in an (maybe-over)simplified example:
CREATE OR REPLACE FUNCTION add_transaction(transaction core_transaction)
RETURNS integer AS $$
DECLARE
transaction2 core_transaction;
BEGIN
transaction.field1 := 'lapse’;
transaction2.field2 := transaction.field2;
transaction2.fi
On 06/02/2015 03:10 AM, Filipe Pina wrote:
HI Adrian,
I had a typo in the email:
INSERT INTO my_table VALUES(my_table.*);
was actually
INSERT INTO my_table VALUES(my_var.*);
Aah, that is different:)
So I meant to insert the variable I had in memory (dict representing a row),
not the row
Thanks Rémi,
Indeed I needed something more generic and easy to maintain (regarding table
schema evolution) so I ended up going back to PL/PGSQL (for that specific
function) in the meantime.
> On 02/06/2015, at 09:41, Rémi Cura wrote:
>
> OUps,
>
> I forget another strategy I used :
> instea
HI Adrian,
I had a typo in the email:
INSERT INTO my_table VALUES(my_table.*);
was actually
INSERT INTO my_table VALUES(my_var.*);
So I meant to insert the variable I had in memory (dict representing a row),
not the rows from the table..
> On 02/06/2015, at 01:44, Adrian Klaver wrote:
>
>
OUps,
I forget another strategy I used :
instead of having
testp2(es employee[])
you can use
testp2( names text[], salaries integer[], ages integer[])
This might be the solution with the less work, but it is absolutely
terrible practice,
because it will be hard to change you record type (evoluti
Hey,
the only straight workaround I know (which is pretty bad)
is to cast down your record to text.
Then you have an array of text, which is manageable.
For this you can either 'flatten' your record into a unique text,
or cast each part of your record to text, then emulate an array of array
(you n
On 06/01/2015 07:42 AM, Filipe Pina wrote:
Thanks for the reply anyway, it's a pity though, it'd be useful..
Another bump I've found along the pl/python road: insert ROWTYPE in table..
Maybe you have some hint on that? :)
So, in PLPGSQL I can:
DECLARE
my_var my_table;
BEGIN
my_var.col1 :
Thanks for the reply anyway, it's a pity though, it'd be useful..
Another bump I've found along the pl/python road: insert ROWTYPE in
table..
Maybe you have some hint on that? :)
So, in PLPGSQL I can:
DECLARE
my_var my_table;
BEGIN
my_var.col1 := 'asd';
INSERT INTO my_table VALUES(my_table
On 5/18/15 10:52 AM, Filipe Pina wrote:
> But one of the functions I need to create needs to accept an array of
> records.
PL/Python doesn't support that. Some more code needs to be written to
support that. You did everything correctly. I don't know of a good
workaround.
--
Sent via pgsql-g
Hello,
I'm building an app in Django and I want to have some functions
directly in postgres. I'd prefer to use pl/python for the functions as
it'd look better in Django migration files (python code within python
code, instead of using PLPGSQL).
But one of the functions I need to create needs
On 11/01/2014 12:13 PM, Peter Eisentraut wrote:
> On 10/15/14 5:58 PM, Jonathan Rogers wrote:
>> BTW, I would rewrite the 9.1 example to be shorter while
>> behaving the same:
>>
>>
>> CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
>> plan = SD.get("plan")
>> if plan is None:
>
> If
On 10/15/14 5:58 PM, Jonathan Rogers wrote:
> BTW, I would rewrite the 9.1 example to be shorter while
> behaving the same:
>
>
> CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
> plan = SD.get("plan")
> if plan is None:
If we're going for shortness, how about
if not plan:
?
On 10/15/14 5:56 PM, Tom Lane wrote:
> Hm ... this was changed in commit 6f6b46c9c0ca3d96. Peter, did
> you consider efficiency here?
Fixed.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ge
On 10/15/2014 05:51 PM, Adrian Klaver wrote:
> On 10/15/2014 02:39 PM, Jonathan Rogers wrote:
>> I was just reading the PL/Python docs section "42.7.1 Database Access
>> Functions" and saw this example:
>>
>> CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
>> plan = SD.setdefault("plan",
Adrian Klaver writes:
> On 10/15/2014 02:39 PM, Jonathan Rogers wrote:
>> I was just reading the PL/Python docs section "42.7.1 Database Access
>> Functions" and saw this example:
>>
>> CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
>> plan = SD.setdefault("plan", plpy.prepare("SELECT 1"))
On 10/15/2014 02:39 PM, Jonathan Rogers wrote:
I was just reading the PL/Python docs section "42.7.1 Database Access
Functions" and saw this example:
CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
plan = SD.setdefault("plan", plpy.prepare("SELECT 1"))
# rest of function
$$ LANGUA
I was just reading the PL/Python docs section "42.7.1 Database Access
Functions" and saw this example:
CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
plan = SD.setdefault("plan", plpy.prepare("SELECT 1"))
# rest of function
$$ LANGUAGE plpythonu;
The above example uses the plpy.prep
Thanks for the confirmation Peter,
I guess I'll take a good look at the existing implementations.
All the best
Seref
On Fri, Aug 9, 2013 at 10:24 PM, Peter Eisentraut wrote:
> On 8/7/13 10:43 AM, Seref Arikan wrote:
> > When a pl/python based function is invoked, does it keep a python
> > run
On 8/7/13 10:43 AM, Seref Arikan wrote:
> When a pl/python based function is invoked, does it keep a python
> runtime running across calls to same function? That is, if I use
> connection pooling, can I save on the python runtime initialization and
> loading costs?
The Python interpreter is initi
Thanks Sergey,
This is going to help for sure. I'll also look at the url. What I've been
trying to understand is when python runtime is invoked during the function
execution (lifecycle?) . Maybe looking at plpython's source may help get an
understanding of that.
Regards
Seref
On Thu, Aug 8, 201
On Wed, Aug 7, 2013 at 7:43 AM, Seref Arikan
wrote:
> When a pl/python based function is invoked, does it keep a python runtime
> running across calls to same function? That is, if I use connection pooling,
> can I save on the python runtime initialization and loading costs?
You can use the follo
Greetings,
Somehow I have failed to find the appropriate keywords for successful
results for my question.
When a pl/python based function is invoked, does it keep a python runtime
running across calls to same function? That is, if I use connection
pooling, can I save on the python runtime initiali
I have installed 64-bit Postgres 9.1 on Windows 7 Enterprise (64-bit). I
also have 64-bit Python 2.7.2 and 2.6 installed. I am interested in using
PL\Python but am having trouble installing it.
I read the intro documentation on PL/Python with respect to the plpython2
vs 3 issues. My installation o
On 10/03/2011 04:14 AM, Sim Zacks wrote:
> I don't know if there is an official definition, but an extension is
> generally a compiled program that is accessed by the SQL. It must be
> compiled with the postgresql headers and have the magic number defined.
> The compiled file must then be put into
Maybe I'm misunderstanding something, but isn't such a sql file an
extension or is 95% of the way there? Pyrseas is already distributed
via PGXN, but like some other PGXN "extensions" (dbi-link?), it doesn't
actually create functions in the database. Its two utilities run
entirely as external
Hi Sim,
On 10/02/2011 08:02 AM, Sim Zacks wrote:
> If I understand plpython correctly, it uses the python installed on the
> machine. In other words, plpythonu doesn't support the new style
> classes, it depends on what version of python is installed.
Well, Python has had new style classes since
On 09/30/2011 05:10 AM, Joe Abbate wrote:
Although there are no discussions or examples in the documentation, I've
determined that PL/Python supports Python new style classes like class
Test(object), and import of standard modules.
Now, in order for to_yaml/to_map to do its
Hi,
I'm toying with the idea of making the Pyrseas utilities a true
PostgreSQL extension. Currently, the utilities (dbtoyaml and yamltodb)
rely on a library of Python functions: over 16 modules and 4000+ lines
of code. The programs would remain as Python command line front-ends,
but there would b
On 03/31/2011 09:58 PM, Davi Duarte wrote:
Hello,
I'm using PL/Python in PostegreSQL 9.0.3 and Python 2.6.5, I want to use
a feature of Python 3, Python have an option to import a module from
future version of Python.
In my case, I want to use the Python 3 division module, because it
returns a
Hello,
I'm using PL/Python in PostegreSQL 9.0.3 and Python 2.6.5, I want to use a
feature of Python 3, Python have an option to import a module from future
version of Python.
In my case, I want to use the Python 3 division module, because it returns a
float division of integers by defaut, whi
Hi,
I recently wrote PL/Python code that worked on fields of composite types.
The plpy.execute() command on a SELECT returns a list of nice dictionaries
keyed on field names, containing the fields. For numeric types, the type
of the dictionary values are as expected. To my chagrin however, if a
OK, I figured some things out. Lines numbers are shown through PL/Python
if it is a syntax error, but not for a runtime error. I'm not sure if
this is because plpython.c only returns a partial stack trace, or what.
The 6 year old TODO list doesn't mention this (but does mention that
array argum
Hi,
Debugging PL/Python isn't as easy as with PL/pgSQL, as it appears I
can't see line numbers where errors occur. For example:
ERROR: plpython: function "evaluate_something" failed
DETAIL: : sequence index must be integer,
not 'str'
The location of this type of exception is difficult to
Hi,
Dean Grubb wrote:
Hi,
plan = plpy.prepare("SELECT last_name FROM my_users WHERE first_name =
$1", [ "text" ])
rv = plpy.execute(plan, [ "name" ], 5)
return rv["last_name"]
If the SELECT command does not return any results, how do I
catch/check for this?
I'm surprised to find you directly
Hi,
plan = plpy.prepare("SELECT last_name FROM my_users WHERE first_name =
$1", [ "text" ])
rv = plpy.execute(plan, [ "name" ], 5)
return rv["last_name"]
If the SELECT command does not return any results, how do I
catch/check for this?
if rv == {} ?
or maybe
try:
rv = plpy.execute(plan, [ "n
36 matches
Mail list logo
