Pavan Deolasee wrote:
I have just counted the number of read/write calls on the CLOG blocks. As
you can
see the total number of CLOG reads jumped from 545323 to 1181851 i.e.
1181851 - 545323 = 636528 CLOG block reads for 1554697 pages of stock
table.
Hmm. So there is some activity there.
Hi, I am now reading PostgreSQL source codes, but i am not familiar to this
codes.
So i am now seraching some sites which explaing about PostgreSQL source
codes, or it's structure.
If you know a good site explaing PostgreSQL's source codes.
Please teach me.
Thanks a lot of your conservation!
On Tue, Jan 23, 2007 at 11:39:23AM -0800, Jeremy Drake wrote:
On Tue, 23 Jan 2007, Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
Hi!
I get failures for the largeobject regression tests on my vc++ build. I
don't
On Wed, 2007-01-24 at 09:32 +0530, Pavan Deolasee wrote:
On a typical desktop class 2 CPU Dell machine, we have seen pgbench
clocking more than 1500 tps. That implies CLOG would get filled up in
less
than 262144/1500=174 seconds. VACUUM on accounts table takes much
longer to trigger.
You
On Wed, Jan 24, 2007 at 12:45:53PM +0530, Pavan Deolasee wrote:
My apologies if this has been discussed before. I went through the earlier
discussions, but its still very fuzzy to me. I am not able to construct a
case
where a tuple is DEAD (not RECENTLY_DEAD) and still there could be
a
On Wed, 2007-01-24 at 14:54 +1100, John Bartlett wrote:
The reason for those 5 options is to consider different means to cover the
Prepared Stmt requirement where the different stages of processing are
actually in different transactions.
John,
Thanks for explaining.
Wow! I've never come
Hi, I'm working with Postgres Source Code too, and there's a site that could
be helpfull
for you as it has been for me.
The site is:
http://www.mcknight.de/pgsql-doxygen/cvshead/html/
Greetings...
2007/1/24, re-plore [EMAIL PROTECTED]:
Hi, I am now reading PostgreSQL source codes, but i am
On 1/24/07, Martijn van Oosterhout kleptog@svana.org wrote:
On Wed, Jan 24, 2007 at 12:45:53PM +0530, Pavan Deolasee wrote:
My apologies if this has been discussed before. I went through the
earlier
discussions, but its still very fuzzy to me. I am not able to construct
a
case
where a tuple
That is also the safe thing to do, since PostgreSQL's implementation
of
WITH HOLD cursors doesn't leave the rows locked. That can lead to the
rows being deleted from under the cursor, for which the standard is
unclear as to whether that is acceptable, or not.
Um, the default use case is to
Pavan Deolasee [EMAIL PROTECTED] writes:
On 1/24/07, Martijn van Oosterhout kleptog@svana.org wrote:
I thought the classical example was a transaction that updated the same
tuple multiple times before committing. Then the version prior to the
transaction start isn't dead yet, but all but one
* Jim Nasby ([EMAIL PROTECTED]) wrote:
On Jan 23, 2007, at 12:07 PM, Stephen Frost wrote:
Hmm. While I agree with the sentiment, Unix does provide for setgid
such that objects inherit a specific group on creation. Using
roles we
don't get that distinction so I don't think comparing it to
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Before discussing limitations you should first justify why we need any
such concept at all. It was no part of the original TODO item and I
cannot see any good use for it.
On 1/24/07, Gregory Stark [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
On 1/24/07, Martijn van Oosterhout kleptog@svana.org wrote:
I thought the classical example was a transaction that updated the same
tuple multiple times before committing. Then the version prior to
On 1/24/07, Stephen Frost [EMAIL PROTECTED] wrote:
Sure, all the objects in a given schema should be owned by a role which
all the admins of that schema are members of. I really see this as a
sensible step from ACLs since ownership implies additional permissions
(which can't otherwise be
On 1/24/07, Merlin Moncure [EMAIL PROTECTED] wrote:
when you create them. Table rights almost always follow broad rules
so it only natural to integrate that with schemas somehow...but
admittedly it is awkward to put it into GRANT (and I've thought alot a
bout.
oops :( what I meant to say here
On Wed, 2007-01-24 at 14:27 +0100, Zeugswetter Andreas ADI SD wrote:
That is also the safe thing to do, since PostgreSQL's implementation
of
WITH HOLD cursors doesn't leave the rows locked. That can lead to the
rows being deleted from under the cursor, for which the standard is
unclear as
Hi Theo
I find your statements about Postgres being a huge business risk pretty
laughable. First of all, Postgres is based on SQL92 and SQL99 standards which
means that most scripts are pretty much the same compared to MSSQL and Oracle.
The only thing I have seen to learn are the postgres
On Jan 24, 2007, at 9:50 AM, John Zubac wrote:
I find your statements about Postgres being a huge business risk
pretty laughable. First of all, Postgres is based on SQL92 and
SQL99 standards which means that most scripts are pretty much the
same compared to MSSQL and Oracle. The only thing
[ redirecting discussion to -hackers, where it seems more appropriate ]
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
FAST PostgreSQL wrote:
Please find attached the patch with modifications
are you proposing to implement the other functions in this TODO item
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
On 1/24/07, Merlin Moncure [EMAIL PROTECTED] wrote:
when you create them. Table rights almost always follow broad rules
so it only natural to integrate that with schemas somehow...but
admittedly it is awkward to put it into GRANT (and I've thought
Ha ha... thx Tino
Yes, I think this is way to go, strange how my mind climbs the wrong tree
sometimes :)
I actually need to aquire a transaction across several dB's, check if the
conditions are right, and then modify some tables, write and remove some
triggers.
Transactions in postgres are 2
We (Oleg and me) are glad to present tsearch in core of pgsql patch. In basic,
layout, functions, methods, types etc are the same as in current tsearch2 with a
lot of improvements:
- pg_ts_* tables now are in pg_catalog
- parsers, dictionaries, configurations now have owner and namespace
Hi, I'm working on a modification of PostgreSQL 8.1.4 and I need to access
the
information stored in the last tuple inserted in a table (All this from the
backend
code).
Could anyone please help me on this?
Greetings and Thanks...
--
Luis D. García M.
Telf: (+58) 2418662663
Cel.: (+58)
Hi,
[EMAIL PROTECTED] wrote:
Ha ha... thx Tino
Yes, I think this is way to go, strange how my mind climbs the wrong
tree sometimes :)
I actually need to aquire a transaction across several dB's, check if
the conditions are right, and then modify some tables, write and remove
some triggers.
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen Potemkin?
I have some ideas myself for how to go about
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Yes your co-employee Jonah.
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00989.php
Sincerely,
Joshua D. Drake
--
=== The
Hello,
I've suscribed to this mailing list for help, I will work on a
Specialization Degree Thesis, this will be a PostgreSQL implementation of
fsql, or fuzzy querys.
http://www.lcc.uma.es/~ppgg/FSQL.html, this is a link to a webpage who made
this in Oracle, but it's not inside of course,
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen Potemkin?
I have some ideas
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
reasons, which I will counter by saying that it looks
On 1/24/07, Stephen Frost [EMAIL PROTECTED] wrote:
err, what proposal wasn't touching the GRANT syntax at all but rather
right, but the original proposal did:
# %Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
which was more or less (with the NEW TABLES
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
one of my new buildfarm boxes (an Debian/Etch based ARM box) is
sometimes failing to stop the database during the regression tests:
Also comparing Postgres to MYSQL is also pretty funny, since there are
instances of MYSQL LOSING databases due to corruption because they do
not have PITR and their transaction rollback feature did not work
properly last time I checked. This is really a issue of people being
close minded to
Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
reasons, which I will
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
This is a fairly large patch and I would like the chance to review it
before it goes in --- we'll commit tomorrow is not exactly a decent
review window.
Peter Eisentraut [EMAIL PROTECTED]
Joshua D. Drake wrote:
Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW - I removed --with-tcl from quagga's configuration about two weeks
ago and it has not failed(for that reason) again. So the issue most
definitly looks like plptcl related ...
It sorta looks like Tcl might be installing an atexit() callback
Andrew Dunstan wrote:
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen
Bruce Momjian wrote:
Wasn't somebody else working on this? Jonah? (Maybe you EDB guys need to
talk more ...)
He is taking it over for Jonah.
Oh, good. That was the piece of missing info. I had a case just
yesterday where this feature would have saved us hours of writing client
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
On 1/24/07, Stephen Frost [EMAIL PROTECTED] wrote:
err, what proposal wasn't touching the GRANT syntax at all but rather
right, but the original proposal did:
# %Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
On Wed, Jan 24, 2007 at 12:56:14PM -0400, Luis D. Garc?a wrote:
Hi, I'm working on a modification of PostgreSQL 8.1.4 and I need to access
the
information stored in the last tuple inserted in a table (All this from the
backend
code).
Could anyone please help me on this?
On Wed, 2007-01-24 at 19:15 +0100, Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW - I removed --with-tcl from quagga's configuration about two weeks
ago and it has not failed(for that reason) again. So the issue most
definitly looks like plptcl related ...
It sorta looks like Tcl might be installing an
On Wed, Jan 24, 2007 at 01:53:54PM -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
Jeremy Drake wrote:
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion.
There has been some prior discussion:
Jeremy Drake wrote:
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
reasons, which I will counter by saying that it looks worse for
marketing reasons because our
Andrew Dunstan wrote:
contrib is a horrible misnomer. Can we maybe bite the bullet and call
it something else?
plugins?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Jeff Davis wrote:
On that point, why do we have /contrib? It's for plugins that are
so version-dependent that they can't exist as a separate project, as
I understand it.
No. (I don't know a better and succinct answer, but that is not it.)
--
Peter Eisentraut
Jeremy Drake wrote:
I for one am greatly looking forward to tsearch2 being in core. I
was very fond of the plugin mechanism, until I signed up with a
hosting provider.
Yes, you have told us about your hosting provider before. Just make
sure your next hosting provider does not refuse to
Peter Eisentraut wrote:
Jeremy Drake wrote:
I for one am greatly looking forward to tsearch2 being in core. I
was very fond of the plugin mechanism, until I signed up with a
hosting provider.
Yes, you have told us about your hosting provider before. Just make
sure your next hosting
Neil Conway wrote:
But I agree that we need considerably more discussion before
committing the patch. I'm personally not sold on the need for
modifications to the SQL grammar, for example, as opposed to just
using a set of SQL-callable functions and some new system catalogs.
In particular, I
Neil Conway wrote:
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion.
There has been some
Peter Eisentraut wrote:
Andrew Dunstan wrote:
contrib is a horrible misnomer. Can we maybe bite the bullet and call
it something else?
plugins?
standard-plugins might be more informative. I think of them as being
like perl's standard modules, things that are part of the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Neil Conway wrote:
Another question that would be easier to resolve before the patch is
committed is naming: the patch currently uses a mix of full text and
tsearch[2] as the name of the full-text search feature. If we're going
to bless this as
Peter Eisentraut wrote:
Jeremy Drake wrote:
I for one am greatly looking forward to tsearch2 being in core. I
was very fond of the plugin mechanism, until I signed up with a
hosting provider.
Yes, you have told us about your hosting provider before. Just make
sure your next hosting
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Where on the website can I see what plugins are included with
PostgreSQL?
YES! That's IMHO a more fundamental problem. The specific
question about Text Search seems more like a symptom. While
I don't mind Text Search in core, it seems an even
Stefan Kaltenbrunner wrote:
sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2
in the current version is actually imposing some additional(often
non-trivial) complexity for things like database restores and
upgrades so I can see an ISP wanting to avoid that altogether.
I
Peter Eisentraut wrote:
Stefan Kaltenbrunner wrote:
sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2
in the current version is actually imposing some additional(often
non-trivial) complexity for things like database restores and
upgrades so I can see an ISP wanting to
Stefan Kaltenbrunner wrote:
I think one can find arguments for both variants - one of the
question might even be how other databases are doing that and if the
proposed syntax is resembling one of those or not.
The closest I could find is Oracle Text, the full-text search for
Oracle. Browsing
I wrote:
The closest I could find is Oracle Text, the full-text search for
Oracle.
Oh, and note that Oracle Text is an extension and not included in the
Oracle database product proper.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
I wrote:
The closest I could find is Oracle Text, the full-text search for
Oracle.
Oh, and note that Oracle Text is an extension and not included in the
Oracle database product proper.
Cool. Then we will have yet another reason to claim we are superior.
Joshua D.
Joshua D. Drake wrote:
Peter Eisentraut wrote:
I wrote:
The closest I could find is Oracle Text, the full-text search for
Oracle.
Oh, and note that Oracle Text is an extension and not included in the
Oracle database product proper.
Cool. Then we will have yet another reason to
On Wed, 2007-01-24 at 18:38 -0300, Alvaro Herrera wrote:
In any case, I agree with Andrew that it would be pretty dumb to reject
a funded, already written patch.
Well, there are two separate issues: should we include tsearch2 in core,
and what syntax should it use? Changing the syntax would not
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think the proper fix is probably to establish a new eval_context
when we enter an EXCEPTION block, and destroy it again on the way out.
Slightly annoying, but probably small next to the other overhead of
a subtransaction.
Neil Conway wrote:
If people had a problem with integrating tsearch2 in core they should
have said so much earlier.
Peter, Tom and others raised essentially identical objections when this
design was initially proposed. For example:
Andrew Dunstan [EMAIL PROTECTED] writes:
IIRC Tom's main objection to the previous proposal was that it involved
large grammar changes, which I understand is not now proposed.
No, they're already in there --- the patch seems to have been written
according to that proposal despite the
On Wed, Jan 24, 2007 at 09:38:06PM +0100, Stefan Kaltenbrunner wrote:
sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2 in
the current version is actually imposing some additional(often
non-trivial) complexity for things like database restores and upgrades
so I can see an
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
IIRC Tom's main objection to the previous proposal was that it involved
large grammar changes, which I understand is not now proposed.
No, they're already in there --- the patch seems to have been written
according to that
On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
On Wed, Jan 24, 2007 at 09:38:06PM +0100, Stefan Kaltenbrunner wrote:
sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2 in
the current version is actually imposing some additional(often
non-trivial) complexity for things
On Tue, Jan 23, 2007 at 09:01:41PM -0600, Jim Nasby wrote:
On Jan 22, 2007, at 6:53 PM, Kenneth Marshall wrote:
The default should
be approximately the OS standard read-ahead amount.
Is there anything resembling a standard across the OSes we support?
Better yet, is there a standard call
Dear Developers,
I would like to suggest the inclusion of an extension
in PostgreSQL. There are instances, I found, when one
needs to INSERT several times the same record in a
table. The front-end application can do it easy in a
loop of a sort, but on remote servers (and that's the
norm these
On Mon, Jan 22, 2007 at 05:11:03PM -0600, Jim C. Nasby wrote:
On Mon, Jan 22, 2007 at 12:17:39PM -0800, Ron Mayer wrote:
Gregory Stark wrote:
Actually no. A while back I did experiments to see how fast reading a file
sequentially was compared to reading the same file sequentially but
On Wed, 2007-01-24 at 08:26 -0800, Sorin Schwimmer wrote:
The front-end application can do it easy in a
loop of a sort, but on remote servers (and that's the
norm these days) it creates unnecessary network
traffic.
You can avoid this easily via a stored procedure.
My suggestion is to allow
On Wed, 24 Jan 2007, Sorin Schwimmer wrote:
Dear Developers,
I would like to suggest the inclusion of an extension
in PostgreSQL. There are instances, I found, when one
needs to INSERT several times the same record in a
table. The front-end application can do it easy in a
loop of a sort,
Sorin Schwimmer [EMAIL PROTECTED] writes:
My suggestion is to allow INSERT to do it REPEAT x.
You can do that today.
INSERT INTO foo SELECT const1,const2,... FROM generate_series(1,1000);
regards, tom lane
---(end of
Kenneth Marshall [EMAIL PROTECTED] writes:
Not that I am aware of. Even extending the relation by one additional
block can make a big difference in performance
Do you have any evidence to back up that assertion?
It seems a bit nontrivial to me --- not the extension part exactly, but
making
[ redirecting thread from -patches to -hackers for wider comment ]
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Tom Lane wrote:
Note I'm not arguing against allowing it to be on by default, I just
want to be sure there is a way for paranoid DBAs to turn it off. Maybe
it'd be
I have removed the developer names from the bottom of the TODO list now
that URLs are used to reference discussions. The URLs are much more
accurate than putting names on items.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard
You should take a look at http://pgfoundry.org/projects/qbe, which deals
with querying data by providing sample data that matches what you're
looking for.
On Wed, Jan 24, 2007 at 01:40:04PM -0400, Werner Echezuria wrote:
Hello,
I've suscribed to this mailing list for help, I will work on a
On Wed, 24 Jan 2007, Tom Lane wrote:
[ redirecting thread from -patches to -hackers for wider comment ]
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Tom Lane wrote:
Note I'm not arguing against allowing it to be on by default, I just
want to be sure there is a way for
On Wed, 24 Jan 2007, Jeremy Drake wrote:
I am digging through the code looking at this, and I have a question. As
far as I can tell, there is currently no owner for a pg_language entry.
Is this correct or is ownership information stored somewhere other than
the pg_language relation? Are you
Patch applied. Thanks.
Backpached to 8.2.X. If it needs to be backpatched to older releases,
someone needs to research that.
---
Kenji Kawamura wrote:
Hello,
This patch fixes a bug of case of extraction of
Jeremy Drake [EMAIL PROTECTED] writes:
I am digging through the code looking at this, and I have a question. As
far as I can tell, there is currently no owner for a pg_language entry.
Er, doh.
Sort of answered my own question, found this comment:
* Note: for now, languages are treated as
Patch applied. Thanks.
---
Guido Goldstein wrote:
Hi!
The attached patch fixes a bug in plpython.
This bug was found while creating sql from trigger functions
written in plpython and later running the generated
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
For a lightly loaded
The only code that is usable (and performant) is the CONNECT BY patch
made by Evgen Potemkin, It works on production servers on the 8.1.5
I hope that a WITH RECURSIVE will be in the 8.3... but I don't see
anybody working on this... (what a shame...)
Le mercredi 24 janvier 2007 à 17:27 +,
Hi there,
sorry, if I will a bit verbose - just tried to answer to several postings.
On Wed, 24 Jan 2007, Tom Lane wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
This is a fairly large patch and I would like the chance to
On Wed, 24 Jan 2007, Neil Conway wrote:
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion.
[EMAIL PROTECTED] (Bruce Momjian) writes:
Fix for plpython functions; return true/false for boolean,
This patch has broken a majority of the buildfarm.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
91 matches
Mail list logo
