On Mar 1, 2011, at 12:10 PM, Jan Urbański wrote:
So you end up with a context message saying PL/Python function %s and
a detail message with the saved detail (if it's present) *and* the
traceback. The problem is that the name of the function is already in
the traceback, so there's no need for
On Dec 23, 2010, at 3:38 AM, Jan Urbański wrote:
Oh, didn't know that. I see that it does some more fancy things, like
defining a inheritance hierarchy for these exceptions and adding some
more into the mix.
Right, there were some cases that appeared to benefit from larger
buckets than what
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
how do you identify which type OID is really hstore?
How about an identification field on pg_type?
CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore';
-- Where the identifier is an arbitrary string.
Type information can be looked up by the
On Aug 9, 2010, at 11:49 AM, Kris Jurka wrote:
Oh, duh. It's a server side copy not going through the client at all. Here's
a hopefully final patch.
Trying it out... Works for me.
I understand the resistance to the patch, but it would be
quite nice to see this wart in the rear view. =\
--
On Aug 14, 2010, at 9:08 AM, Tom Lane wrote:
Just to clarify, you're recommending something like
proc-me = PyCObject_FromVoidPtr(proc, NULL);
+ if (proc-me == NULL)
+ elog(ERROR, could not create PyCObject for function);
On Aug 13, 2010, at 5:20 PM, Tom Lane wrote:
According to a discussion over in Fedora-land, $subject is true:
http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html
I see several calls in plpython.c that seem to refer to PyCObject stuff.
Anybody have any idea if we need to do
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I imagine.
But, I
On Jul 25, 2010, at 8:01 AM, Kris Jurka wrote:
The JDBC driver reads server messages for multiple reasons.
One of them is indeed to do early failure detection.
That's high quality. =)
Another is to pickup NoticeResponse messages to avoid a network buffer
deadlock.
That's a good catch. I
On Jul 28, 2010, at 9:53 AM, Kris Jurka wrote:
Technically you won't get NotificationResponse until transaction end, so you
don't need to worry about that mid copy.
Ah, thanks for noting that. It would appear my original reading of the async
section didn't get far enough beyond Frontends must
On Jul 23, 2010, at 7:11 AM, Tom Lane wrote:
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ...
I was wondering the same thing when I first saw Kris' message. However, iff I
understand what JDBC is trying to achieve, I don't think I would call it
On Jul 7, 2010, at 12:07 AM, Peter Froehlich wrote:
I joined this list under the mis-impression that it was about hacking
the Python interfaces to pgsql. Is there possibly another list for
that? Or is the Python stuff just mixed in with all the rest? Sorry
for the meta-question...
For BSD/MIT
On Feb 1, 2010, at 12:18 PM, James William Pye wrote:
Right now, I'm trying to trim some of the easy issues[1] and getting a
project web page up. I expect to be able to make a release soon, and I'll
follow-up to this thread when I do.
Well, I ended up doing some others things at that point
On Apr 20, 2010, at 10:03 PM, feng tian wrote:
Another way to do this, is to send the client an redirect message. When
client connect to 127.0.0.10, instead of accepting the connection, it can
reply to client telling it to reconnect to one of the server on
127.0.0.11-14.
ISTM that this
On Nov 10, 2009, at 9:54 AM, Bruce Momjian wrote:
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
Heikki Oops, you're right. The check is indeed confusing julian day
Heikki numbers, with epoch at 23th of Nov 4714 BC, with
Heikki postgres-reckoning day numbers, with
On Feb 6, 2010, at 5:51 PM, Josh Berkus wrote:
Finally, I just don't see the existing (often PG specific) goals that I have
in mind for it appealing to the majority of [web framework/abstraction]
users.
What are those goals?
I think the most interesting one that has yet to be implemented
On Feb 5, 2010, at 1:34 PM, Marko Kreen wrote:
py-postgresql seems to be more serious, but as it's python3 only
which makes it irrelevant today.
Furthermore, if it did work on python2, it's *not* something that's going to
appeal to mainstream users (Python heavy web frameworks) as it
On Feb 5, 2010, at 11:34 AM, Josh Berkus wrote:
For people who use Python a lot, could I have a list of the deficiencies
in DBAPI? I've got my horse and lance ready.
Given that SQLAlchemy isn't for everyone, of course ... it couldn't be,
or Django would use it, no?
Here are some to start
On Feb 5, 2010, at 8:00 AM, Peter Eisentraut wrote:
I think another difference is that the Perl DBI interface is very rich,
whereas the Python DB-API is quite minimal and almost forces people to
write (incompatible) extensions.
Yep.
The DB-SIG at Python that ought to drive all this is also
On Feb 1, 2010, at 11:29 AM, Joshua D. Drake wrote:
On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly. If the user community
On Feb 1, 2010, at 2:13 PM, Bruce Momjian wrote:
I would love to know why PL/Python can't be incrementally improved like
the rest of our code.
AFAICT, there are two primary, perhaps identifying, parts to a PL extension:
code management (compilation, execution, etc) and type I/O (conversion in
On Feb 1, 2010, at 1:23 PM, Nathan Boley wrote:
I think it would be great for you to review it... I doubt that will
cause it to get committed for 9.0, but my doubt is no reason for you
to hold off reviewing it.
I assumed so, but the pretense of a chance will probably help to motivate me
On Jan 30, 2010, at 3:36 PM, Ivan Sergio Borgonovo wrote:
For development purposes you would be far better off building a
private version of postgres (with configure --prefix=/path) and
using its pgxs to build, install and test your module.
That's pretty expensive.
eh:
On Jan 27, 2010, at 1:00 PM, Joe Conway wrote:
Implementing true value_per_call is still something on my TODO list, but
obviously has not risen to a very high priority for me as it has now
been an embarrassing long time since it was put there. But that said,
materialize mode has proven
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
Here's the trigger example which should help reveal some of the advantages of
native typing. This is a generic trigger that constructs and logs
manipulation statements for simple
On Jan 20, 2010, at 12:27 PM, Magnus Hagander wrote:
Well, it needs the version to match it to the DLL name. For python
2.6, it needs python26.dll. But yes, there should probably be some way
to ask python itself about that - that would be the non-naive method.
But as long as python is
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
What I would (as a non hacker) would look for is:
(1) Generalized benchmarks between plpython(core) and plpython3u
I know a lot of these are subjective, but it is still good to see if
there are any curves or points that bring the
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
So far, I have three specific examples in mind:
The first will illustrate the advantages of function modules wrt setup code in
the module body. Primarily this is about convenience.
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
Here's the first example. This covers an advantage of function modules.
This is a conversion of a plpythonu function published to the wiki:
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
What I would (as a non hacker) would look for is:
(1) Generalized benchmarks between plpython(core) and plpython3u
I know a lot of these are subjective, but it is still good to see if
there are any curves or points that bring the
On Jan 14, 2010, at 12:17 AM, Greg Smith wrote:
Code samples.
Okay.
I don't know, because even with several thousand lines of basic Python code
to my credit I cannot understand a single one of the arguments you presented
for why your implementation is better--except agreeing that, yes,
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
Doing so, succinctly, is unfortunately difficult.
It is primarily a
On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
The problem I'm having with this discussion is that every time someone
asks what the supposed advantages of this new Python PL are, a feature
list like the above is dumped,
I agree that this is unfortunate, but how else can we to discuss the
On Jan 13, 2010, at 12:15 PM, Robert Haas wrote:
1. It's not just a rewrite, it's an incompatible rewrite that will
present significant user-visible behavioral differences. So replacing
the current implementation wholesale would produce massive breakage
for anyone actually using PL/python in
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote:
This looks like it's most likely redundant with the stuff I added
recently for the plpgsql parser rewrite. Please see if you can use that
instead.
The parser param hooks will definitely work. As for getting the result
TupleDesc prior to
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote:
Why not code a loop around one of the existing SPI execution functions?
*shrug* seemed nicer to push it on the parser than to force the user to split
up the statements/calls. Or split up the statements myself(well, the parser
does it so swimmingly
On Dec 20, 2009, at 1:36 AM, Peter Eisentraut wrote:
Please check that it is sane.
I'm up, so:
Works for me on snow leopard.
But it doesn't seem to want to stop configure'ing on my fbsd8/amd64 box:
$ ./configure --prefix=/src/build/pg85a3
$ gmake # GNU make 3.81
keeps running configure again
On Dec 20, 2009, at 9:20 AM, Tom Lane wrote:
Usually that means timestamp skew, ie file timestamps are later than
your system clock.
Yep. It's working now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
In the event that my plpython3 patch does not make it, it seems prudent to try
and get a *much* smaller patch in to allow the PL to easily exist out of core.
I added a couple SPI functions in order to support the database access
functionality in plpython3u. Also, a getelevel() function for
On Jun 13, 2008, at 9:24 AM, Tom Lane wrote:
You'd do it while Binding a FETCH command.
Indeed, that is true. It seems quite unfortunate that drivers
have to jump through such hoops to provide a convenient
programmer's interface to held and/or scrollable cursors; bearing in
mind all that has
On Jun 13, 2008, at 4:40 PM, Kris Jurka wrote:
The JDBC driver would also like this ability, but a GUC is a pretty
ugly hack.
I completely agree that it is an ugly hack. :)
Also, since you still have to go to the SQL level to issue the MOVE
or FETCH BACKWARD, you're still not all the way
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
Or perhaps configuring it so after binding it?
I know you can use DECLARE, but I believe that this inhibits the
driver from being
able to select the transfer format for individual columns; it's all
binary or
On Jun 12, 2008, at 10:08 AM, Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
No, and for at least the first of those I don't see the point,
since the protocol doesn't offer any behavior other than
On Jun 12, 2008, at 3:59 PM, Tom Lane wrote:
Sure, but if you're willing to use a SQL-level operation on the portal
then you could perfectly well declare the cursor at SQL level too.
Indeed, but like I said in my initial e-mail::
I know you can use DECLARE, but I believe that this inhibits
On Jun 12, 2008, at 4:45 PM, Tom Lane wrote:
Huh? I don't see why... you might have such a limitation in a
particular driver, but not in the protocol.
Oh? I know when you bind a prepared statement you have the ability
state the formats of each column, but I'm not aware of the protocol's
You guys call this simplification? You're out of your minds.
This proposal is ridiculously complicated, and yet it still fails
even to consider adjusting non-numeric parameters. And what about
things that require more than a trivial arithmetic expression to
compute? It's not hard at all to
On Tue, Jun 03, 2008 at 01:17:43AM -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I would like to add the flags given to pg_dump into the output of the
pg_dump
file.
+1, FWIW
Anyone see any issues with this?
I'm a bit worried about breaking diff-equality of matching
On Mon, Jun 02, 2008 at 08:10:19PM +0200, Pavel Stehule wrote:
* I have a mild preference for array_fill instead of array_init.
maybe, maybe array_set. Any ideas are welcome
array_create?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
or put a hopefully-cleaner design into
On Sun, May 28, 2006 at 09:12:34PM -0400, Tom Lane wrote:
But we're still avoiding the central issue: does it make sense to dump a
probin clause at all for plpython functions? If it's a compiled form of
prosrc then it probably doesn't belong in the dump.
That's why I initially thought pg_dump
On Fri, May 26, 2006 at 11:21:32PM -0400, Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
So is this fix your broken PL or pg_dump should only be doing that for C
language functions?
Offhand it seems to me that pg_dump is behaving reasonably: it's storing
probin if it sees
Hi,
In PL/Py, I had the bright idea of storing bytecode in the probin field of the
function's pg_proc row. However, this idea has lately become rather dim as I
have recently rediscovered(thanks Adrian) that this breaks dumps; pg_dump
outputs
a PL/Py function as CREATE FUNCTION x() RETURNS y
On Sun, May 07, 2006 at 12:16:16AM +0200, Thomas Hallgren wrote:
Yes, the intarray stuff was very helpful but also somewhat confusing.
Why are there two ways of representing some of the array types? I mean,
why is there an _int4 when you could just as well write int4[]? I'm
probably missing
an
overzealous version.]
Any thoughts and directions would be appreciated.
--
Regards, James William Pye
ciinsert.patch.gz
Description: Binary data
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
for certain
applications.)
--
Regards, James William Pye
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
?
--
Regards, James William Pye
---(end of broadcast)---
TIP 6: explain analyze is your friend
if this is different on 8.0 or earlier.)
[1] http://www.postgresql.org/docs/8.1/static/runtime-config-client.html
--
Regards, James William Pye
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
#
Postgres.NOTICE(repr(code))
$$;
CREATE TRUSTED LANGUAGE plpyr HANDLER python.handler VALIDATOR zope_restrict;
[This almost works in plpy head, but I think I just found a bug ;]
--
Regards, James William Pye
---(end of broadcast)---
TIP 2: Don't 'kill -9
it or to give it much thought.
--
Regards, James William Pye
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
be used. However, it does mean that some
munging of the handler would be required(Something that I desired to avoid).
--
Regards, James William Pye
---(end of broadcast)---
TIP 6: explain analyze is your friend
. Not that that would kill it, but I think there is a better way; I'm
cooking up a general proposal for refactoring unique constraints, so I'm hoping
something along those lines will aid any patch attempting to solving this
problem[copy error/violation management].
--
Regards, James William Pye
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within the context of the command.
Perhaps a WARNING or NOTICE
trivial modifications to get it
to work with UNLESS without any redundancy.
--
Regards, James William Pye
---(end of broadcast)---
TIP 6: explain analyze is your friend
should/will be applied after BEFORE
triggers, but before non-UNLESS specified constraints. ;)
--
Regards, James William Pye
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
William Pye
Index: src/backend/access/nbtree/nbtinsert.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v
retrieving revision 1.131
diff -c -r1.131 nbtinsert.c
*** src/backend/access/nbtree/nbtinsert.c
a
libinitdb, or some sort authoritative source of processing steps in
order to initialize a new database location that other applications
could make easier use of?
--
Regards, James William Pye
iCrossing Privileged and Confidential Information
This email message is for the sole use of the intended
/pgsql-hackers/2005-05/msg00331.php
Hope it helps.
--
Regards, James William Pye
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
postgresql.utility.config
The 'layout' package needs to be installed first.
See this quick start section:
http://python.projects.postgresql.org/quick.html#Fetch+and+Install+the
+Backend
('be' depends on 'lo' and 'ex')
--
Regards, James William Pye
---(end of broadcast
. See
http://docbook.org/tdg5/en/html/qandaset.html
--
Regards, James William Pye
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
in multiversion supporting clients and
to do so without any version specific code(or at a minimum wrt older
servers) or fingerprinting of any sort.
--
Regards, James William Pye
---(end of broadcast)---
TIP 6: explain analyze is your friend
).
--
Regards, James William Pye
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
see
that the trial and error process would only need to happen once(per
process, I figure) if the client author cached the code selection
information about a given server.
Thoughts? Has this been proposed/shot down before?
--
Regards, James William Pye
---(end of broadcast
as selecting feature implementations
based on it is probably a bad idea(TM).
--
Regards, James William Pye
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
by connection cycle you are referring to reopening
the socket, or...?
--
Regards, James William Pye
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes
to read the
function code as a specific encoding, one must use, afaik, the # -*-
encoding: utf-8 -*- magic.
--
Regards, James William Pye
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs
on IRC and I'm still curious, does PG have a API styling
standard/guide? I see formatting and info about error messages, but
nothing about function/global/typedef naming.
--
Regards, James William Pye
---(end of broadcast)---
TIP 1: subscribe
://python.projects.postgresql.org
[2]http://python.projects.postgresql.org/project/be.html
[3]http://python.projects.postgresql.org/license.html
[4]http://lists.pgfoundry.org/mailman/listinfo/python-general
[5]http://python.projects.postgresql.org/quick.html
--
Regards, James William Pye
On Sat, 2005-04-30 at 16:17 -0400, Tom Lane wrote:
An example that Elein put up yesterday:
http://archives.postgresql.org/pgsql-general/2005-04/msg01384.php
caused me to realize that type output functions that depend on
additional arguments to determine what they are dealing with are
-general
[5]http://python.projects.postgresql.org/quick.html
--
Regards, James William Pye
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
, as a user could also try to dereference a NULL pointer from
an extension module as well. ;)
I feel if I were to implement such restrictions/regulations it would be
analogous to a security guard trying to enforce the law, whereas a real
police officer is needed.. ;-)
--
Regards,
James William
/2004-07/msg00505.php
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00569.php
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
/project/postgrespy/cvs/co.php/imp/src/query.c?r=HEAD
http://gborg.postgresql.org/project/postgrespy/cvs/co.php/imp/src/portal.c?r=HEAD
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
them. If they are provided for possible use,
shouldn't they take a string instead of a List? (Is a List used here to
discourage use?)
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
this information, but
[something like] this is considerably more convenient, IMO.
--
Regards,
James William Pye
Index: configure.in
===
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.383
diff -c -r1.383 configure.in
the components for use in my source. (;
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
] modules in Python's
site-packages.
AFA hardwiring is concerned, I will probably make it a GUC variable in
8.0 that will default to how I currently hardwire it.
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
On Tue, 2004-09-21 at 17:13, Neil Conway wrote:
Should this be documented in the installation instructions?
I think so.
I figure just a mention should be enough.
(Also add some productname tags around 'Python'.)
--
Regards,
James William Pye
Index: installation.sgml
installed)
(Note that I just did it with my dev build without trouble)
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
psql clients should be able to connect to 7.4
backends (;
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
there would probably be others who would
appreciate it.)
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
os.path.join(f(plat_specific=1,standard_lib=1),'config')
/usr/local/lib/python2.3/config
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
On Thu, 2004-09-09 at 12:28, James William Pye wrote:
That should work, regardless of the lib directory that Python is
installed to.
Looking at get_python_lib(), I'm not so sure that I'm correct:
if os.name == posix:
libpython = os.path.join(prefix
arrays is the requirement.
+1
This would probably make MD array support in plpy almost trivial, so it is
definitely desirable to me.
--
Regards,
James William Pye
pgpnxxoAV7fns.pgp
Description: PGP signature
set isDone to
ExprMultipleResult on _every_ call while returning values, as it will break
out if rsinfo.isDone != ExprMultipleResult.
Is this the desired behavior?
--
Regards,
James William Pye
pgp5jFzzXeeDI.pgp
Description: PGP signature
came in when I implemented SRFs that worked with non-table
SRFs, and then table functions didn't work because I wasn't setting isDone
to MultipleResult every call.
--
Regards,
James William Pye
pgpoHdRYbOzbM.pgp
Description: PGP signature
noticed any stability issues. If it
were shockingly unstable, I would have expected to have had problems with
it.
Using the ssh tunnel, served on an fbsd jail(yeah, rented from Marc), and
connecting with svn client 1.0.4 on my home fbsd 4.10 box..
--
Regards,
James William Pye
;
Aye, good idea.
--
Regards,
James William Pye
pgpVR2RlKrgUv.pgp
Description: PGP signature
, and it can be quite nice to
have a macro interface to allow the underlying to change willy-nilly(not
that it should, but that it can). I'll bet that's the hardly any improvement
that you mentioned.
--
Regards,
James William Pye
pgp1kRiCAv5XB.pgp
Description: PGP signature
that FmgrInfo is statically
declared/allocated is many places..
--
Regards,
James William Pye
pgpGrvIR3fGuo.pgp
Description: PGP signature
in plpgsql_exec_function()
Also, return next is only allowed if fn_retset: In gram.y, line ~1179.
and probably any other callee that is coded to handle both cases.
Aye. Can't argue with that.
Regards,
James William Pye
pgpCCTm1n2ksA.pgp
Description: PGP signature
0x8153d56 in PortalRun ()
#9 0x8153c56 in PortalRun ()
#10 0x8150d87 in pg_plan_queries ()
#11 0x815310f in PostgresMain ()
#12 0x8107096 in main ()
#13 0x806d772 in _start ()
Probably more info than you need/want, but gdb is fun, so here's lots! 8)
Regards,
James William Pye
Index
1 - 100 of 103 matches
Mail list logo
