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
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 th
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");
> P
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 t
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
>
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 was able to trigger the
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 mu
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.
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
"over
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/
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 ot
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
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
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 imple
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 a
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 st
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 *partial
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
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 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 com
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:
j...@torch[]:
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 extr
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 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 per
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 insta
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:
http://wiki.postgresql.org/wiki/Google_T
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 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 per
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 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
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 t
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 ma
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 executi
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:
http://www.postgresql.org/ma
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
... (last few lines before i
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
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 condi
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 t
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 be
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 im
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
capaci
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 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 an
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 i
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 o
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 s
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 c
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_du
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_dum
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 LANG
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 miss
e more unique constraint violations that occur, the more I/O that gets saved
with insert scans. I imagine this could be a very good thing for certain
applications.)
--
Regards, James William Pye
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
f the whitespace changes in the patch, remnants from 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
y here.
(Not sure 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 appropr
eation?
--
Regards, James William Pye
---(end of broadcast)---
TIP 6: explain analyze is your friend
tation).
This doesn't mean that it couldn't 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
sure as I
have yet to test 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
ope restriction stuff, raise exception if necessary
#
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' the postmaster
but I believe some additional locking is required in order to make that
safe. 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
7; and return
the state(position, locks, whether an entry exists, anything else necessary for
a quick insert) of that scan to the caller for later use in the actual insert or
update. All other constraints appear to require 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
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
should be
made with respect to triggers. So, UNLESS 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
rendered these results are available on request. They are 100K a
piece after being bzip'd)
--
Regards, James William Pye
Index: src/backend/access/nbtree/nbtinsert.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/acc
case, it would be overkill, but what about 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
tgresql.org/pgsql-hackers/2005-05/msg00331.php
Hope it helps.
--
Regards, James William Pye
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ibution.config = cfg = self.load()
> File "/home/hannu/work/postgresPy/be/lib/ldistutils.py", line 129, in
> load
> cfgsrc(self)
> File "setup.py", line 19, in configure
> import postgresql.utility.config
> ImportError: No module named postgresql.utility.conf
ents specifically for
structuring FAQ material. 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
e done once(save various exceptions, of course).
--
Regards, James William Pye
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
oritatively
resolve ambiguity that may exist 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
ht answer and then do it, you
> will always expend two connection cycles. That is a win how exactly?
Like I asked above, why does it have to be done in two connection
cycles? I'm assume by connection cycle you are referring to reopening
the socket, or...?
--
Regards, James William Pye
---
eally, I'm not sure if such a feature
should include the server version 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
cket?). Although, I do 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
---
ng()))
PyEncoding_FromPgEncoding is defined in encoding.c.
Also, it should be noted that to get the interpreter to read the
function code as a specific encoding, one must use, afaik, the # -*-
encoding: utf-8 -*- magic.
--
Regards, James William Pye
---(end of broa
think it would be a good goal to have.
...
I asked 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 broa
sitate to contact me by e-mail or on freenode where
I go by the nick 'jwp'.)
[1]http://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/py
]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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
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
> fund
enforce the law, whereas a real
police officer is needed.. ;-)
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
ls?]:
http://archives.postgresql.org/pgsql-hackers/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
uld probably think about writing your own SPI.
While a ways from complete/stable, my Python "SPI":
http://gborg.postgresql.org/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
ontaining the savepoint name. I get the feeling that I
am not meant to use 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
best to keep Python [extension] 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
defining the components for use in my source. (;
--
Regards,
James William Pye
signature.asc
Description: This is a digitally signed message part
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
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: inst
.2 backend.
AFAIK, this is fine, 8.0 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
ewhere here, if you have multiple
versions 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
check for it anyways.
(Gaetano requested it so there would probably be others who would
appreciate it.)
--
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":
libpy
t get_python_lib as
f; import os; print
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
is, but my interpretation of SQL99 is
> that nested 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
From my casual usage of svn, I haven't 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..
--
d?
My confusion 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
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
er
> direct use of the setjmp API.
Well, I find it more aesthetically appealing, 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
inefficient. A further improvement would be to replace
> Warn_restart by a pointer defined like
> extern sigjmp_buf *exception_stack_top;
Aye, good idea.
--
Regards,
James William Pye
pgpVR2RlKrgUv.pgp
Description: PGP signature
nt_ success, caught an
ERROR, and continued on my merry way without raising it. To say the
least, it was done without elegance as the client is likely to get
the ERROR message from errstart. That and the fact that I cannot access the
static ErrorData is what kept me from keeping that functionality.
(I basically stored and restored the state of a couple globals which may have
been changed by an elog(ERROR), ie, InError)
--
Regards,
James William Pye
pgpyI2cKg2mlM.pgp
Description: PGP signature
tion, as it assumes FmgrInfo is allocated by Postgres's memory
manager, and after a quick grep I see that FmgrInfo is statically
declared/allocated is many places..
--
Regards,
James William Pye
pgpGrvIR3fGuo.pgp
Description: PGP signature
;t see why plpgsql would act any differently if it
were given a not null RSI when !fn_retset, considering that it only seems
to use it when fn_retset is true.
I didn't test it, so I might need to eat my hat, but...
Line 353 of pl/plpgsql/pl_exec.c in plpgsql_exec_function()
Also, return nex
1 - 100 of 104 matches
Mail list logo
