On Thu, 16 Sep 2004, Greg Stark wrote:
>
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > whereas adding support for CALL to SQL is part of proper support for stored
> > procedures. Gavin and I are hoping to send a proposal for the latter to
> > -hackers in a few days.
>
> What is the point of stor
Neil Conway <[EMAIL PROTECTED]> writes:
> whereas adding support for CALL to SQL is part of proper support for stored
> procedures. Gavin and I are hoping to send a proposal for the latter to
> -hackers in a few days.
What is the point of stored procedures being distinct from functions anyways?
Oliver Jowett <[EMAIL PROTECTED]> writes:
> > Well benefits that boil down to "Java sucks" aren't very convincing. Perl
> > suffers from no such handicap.
>
> Arguing that Java-specific benefits are not convincing benefits for a JDBC
> driver because you don't get them in Perl seems a bit odd to
Greg Stark wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
There *are* benefits to implementing the protocol directly. First on my
personal list is that our Java application would not be able to use postgresql
at all if the driver required JNI/libpq.
Well benefits that boil down to "Java sucks" a
We have discovered an interesting locking scenario with Slony-I that
is pointing to a use for the ability to exclude certain schemas from
pg_dump.
The situation is that when a "full" pg_dump kicks off, a Slony-I
"create sync" event, which expects to "LOCK slony_schema.sl_event;",
is blocked from g
Good morning
Let me introduce, I'm Ricardo Rezende and I'm SQL Magazine subeditor, from Brazil (http://www.sqlmagazine.com.br.).
My goal in this first contact is to solve a doubt about PostgreSQL RDBMS.
I'm writing an article about redundant storage technology, called RAID. The first part of th
Tom Lane schrieb:
Had you been running the server for very long before forcing the error,
I don't think this would have happened, because the buffer hashtable
would have already expanded to its full working size.
Yes, you are right - this was a fresh started pgserver.
Once we fix subxacts to not ho
HI,
I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
SO SLOW at committing inserts and deletes into a large database. One
of the many slowdowns was from MemSet. I found an old (2002) thread
about this and retried the tests (see below). The main point is that
the system m
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>
> > I was pretty shocked when I heard that JDBC implements the low level protocol
> > itself. It seems like a dead-end strategy to me. Any new protocol innovations
> > need to be implemented in every driver. Every implementation get
On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
> ISTM that this is being done at the wrong level anyway. I'd like to see
> a facility available in our SQL, e.g.
>
> CALL foo();
>
> with the restriction that foo() should be declared to return void.
I think these are two distinct issues. Th
On Sep 16, 2004, at 7:52 AM, Marc G. Fournier wrote:
In recognition of his role as lead developer on the
internationalization front, as well as his invaluble work in both the
build and release processes, Peter Eisentraut has been invited, and
has accepted, to join the Core Committee.
Congratulat
Mike Mascari <[EMAIL PROTECTED]> writes:
>> See http://developer.postgresql.org/bios.php
> What ever happened to the idea of specially recognizing Thomas
> Lockhart and Vadim Mikheev in a Hackers Emeritus section?
I think it's a good idea, but it doesn't look like anyone ever
got round to it.
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Wow - I always thought Peter WAS on the core committee Who is on it?
See http://developer.postgresql.org/bios.php
What ever happened to the idea of specially recognizing Thomas
Lockhart and Vadim Mikheev in a Hackers Emeritu
> In recognition of his role as lead developer on the internationalization
> front, as well as his invaluble work in both the build and release
> processes, Peter Eisentraut has been invited, and has accepted, to join
> the Core Committee.
Congrats Peter,
... John
--
On Thu, 16 Sep 2004, Christopher Kings-Lynne wrote:
In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
Congratulat
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Wow - I always thought Peter WAS on the core committee Who is on it?
See http://developer.postgresql.org/bios.php
regards, tom lane
---(end of broadcast)---
TIP 4: D
In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
Congratulations, Peter!
Wow - I always thought Peter WAS on the
On Wed, Sep 15, 2004 at 10:56:28PM +0100, Simon Riggs wrote:
> There are many good ideas out there, yet it is almost impossible to find
> somebody else to implement yours!
>
> The acid test is to try and write it...
>
> Overall, I agree VACUUM could do with some tuning - and 8.0 has just that.
>
Marc G. Fournier wrote:
In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
Good work, Peter.
Regards
Gaetano Mendol
On Thu, 2004-09-16 at 01:05, Tom Lane wrote:
> That seems fairly unworkable. For example
>
> SELECT (2,3,4);
>
> is valid SQL.
Good point. The disambiguation algorithm I suggested isn't sufficient,
but I think there ought to be _some_ reasonable algorithm.
>From glancing over the SQL com
Replying to my own post, thanks to the assistance of Paul
Bort...
On Wed, Sep 15, 2004 at 11:43:47PM +1000, Chris Dunlop wrote:
> There seems to be a kind of statement parsing problem in 7.4.5
> (from debian postgresql-7.4.5-3, i386).
>
> Either that, or I'm missing something...
>
> \echo -
On Thu, 2004-09-16 at 08:52, Marc G. Fournier wrote:
> In recognition of his role as lead developer on the internationalization
> front, as well as his invaluble work in both the build and release
> processes, Peter Eisentraut has been invited, and has accepted, to join
> the Core Committee.
Co
Joe Conway wrote:
> One procedural issue did occur to me regarding this kind of change.
> It requires someone to run autoconf after applying -- how is that
> normally handled?
You run autoconf before you commit and then check it in. Please use
version 2.53.
--
Peter Eisentraut
http://developer
Marc G. Fournier schrieb:
> In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
Glückwunsch!
--
Reini Urban
http://xa
In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
Marc G. Fournier Hub.Org Networking Services (ht
On Wed, Sep 15, 2004 at 01:34:01PM -0400, Tom Lane wrote:
> After looking over the state machine in xact.c, I'm thinking of removing
> the TBLOCK_SUBENDABORT_ALL and TBLOCK_SUBENDABORT_RELEASE states in
> favor of having the ROLLBACK command mark the whole transaction state
> stack similarly to wha
On Wed, Sep 15, 2004 at 09:50:17PM +0100, Simon Riggs wrote:
> >Mark Wong wrote
> > Hi Simon,
> >
> > Sorry it has taken so long. Among other things, I doubled the controllers
> > and drives on the system I was testing this on. But now I have some data
> > against PostgreSQL-8.0beta2.
> >
>
> Th
> Jim C. Nasby wrote
> I just had a thought that could potentially greatly improve vacuum
> performance. What about some kind of TID (or does vacuum use CID?)
> index? This would allow vacuum to visit only the pages it needs to
> visit. Actually, I guess TID/CID wouldn't even be involved; the only
Greg Stark wrote:
I was pretty shocked when I heard that JDBC implements the low level protocol
itself. It seems like a dead-end strategy to me. Any new protocol innovations
need to be implemented in every driver. Every implementation gets the chance
to reimplement the same bugs and same inefficien
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Conway wrote:
| Gaetano Mendola wrote:
|
|> python -c "from distutils import *" > /dev/null 2>&1 || (echo "You
|> need distutils installed"; exit 1)
|>
|
| Sorry for the delay -- things got busy around here all of a sudden.
|
| Attached is a version
Gaetano Mendola wrote:
python -c "from distutils import *" > /dev/null 2>&1 || (echo "You need
distutils installed"; exit 1)
Sorry for the delay -- things got busy around here all of a sudden.
Attached is a version of the patch with James Pye's distutils checking
code. Gaetano, please verify it
>Mark Wong wrote
> Hi Simon,
>
> Sorry it has taken so long. Among other things, I doubled the controllers
> and drives on the system I was testing this on. But now I have some data
> against PostgreSQL-8.0beta2.
>
Thanks very much.
> Here is the test run with archiving enabled:
> http://
I just had a thought that could potentially greatly improve vacuum
performance. What about some kind of TID (or does vacuum use CID?)
index? This would allow vacuum to visit only the pages it needs to
visit. Actually, I guess TID/CID wouldn't even be involved; the only
information needed would be i
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 15, 2004 11:34 AM
> To: Tom Lane
> Cc: Dann Corbit; Greg Stark; Merlin Moncure;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
>
>
>
> Tom
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Is there anything technically hard in adding this functionality to libpq? It
> > looks like it's just mechanically adding more entry points to existing code.
>
> Well, (a) I ran out of time, and (b) I wasn't sure wh
Tom Lane <[EMAIL PROTECTED]> writes:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > What about using ECPG as an interface for drivers?
>
> What for? It's not a substitute for libpq --- it sits on top of libpq,
> or did last I checked anyway. And it's designed around a preprocessor
> that seem
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> What about using ECPG as an interface for drivers?
What for? It's not a substitute for libpq --- it sits on top of libpq,
or did last I checked anyway. And it's designed around a preprocessor
that seems fairly useless for a driver.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Wednesday, September 15, 2004 10:51 AM
> To: Greg Stark
> Cc: Merlin Moncure; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
>
>
> Greg Sta
Greg Stark <[EMAIL PROTECTED]> writes:
> Is there anything technically hard in adding this functionality to libpq? It
> looks like it's just mechanically adding more entry points to existing code.
Well, (a) I ran out of time, and (b) I wasn't sure what the most
convenient API would be. Should we
Tom Lane <[EMAIL PROTECTED]> writes:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Question: what is the relevance of the binary protocol, are you trying
> > to send/fetch binary data via the command interface?
>
> My understanding of the original post is that DBD::Pg is sitting atop
> libp
After looking over the state machine in xact.c, I'm thinking of removing
the TBLOCK_SUBENDABORT_ALL and TBLOCK_SUBENDABORT_RELEASE states in
favor of having the ROLLBACK command mark the whole transaction state
stack similarly to what is now done for COMMIT. In detail this would
require adding a T
"Katsaros Kwn/nos" <[EMAIL PROTECTED]> writes:
> What I'm trying to do is to get the Query related to a select statement,
> alter it and produce a new SPI_plan that will execute. To do so, I
> retrieve the query from the _SPI_plan->qtlist, alter it (seems OK in
> nodeToString) and then use some SPI
On Wed, 2004-09-15 at 09:15, G u i d o B a r o s i o wrote:
> [EMAIL PROTECTED] local]$ psql template1
> Welcome to psql 8.0.0beta2, the PostgreSQL interactive terminal.
> template1=# select version();
>version
> --
Andrew Dunstan wrote:
ISTM that this is being done at the wrong level anyway. I'd like to see
a facility available in our SQL, e.g.
CALL foo();
with the restriction that foo() should be declared to return void. Of
course, that doesn't remove the keyword requirement as Neil wanted, but
doing th
G u i d o B a r o s i o <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] postgres]$ createlang plpgsql tech_mis
> createlang: language installation failed: ERROR: could not load library
> "/usr/local/pgsql/lib/plpgsql.so": /usr/local/pgsql/lib/plpgsql.so: undefined
> symbol: PG_exception_stack
I
Hi!
I posted the following message to the general list but no answer.Could
you please help?
I have some problems with the SPI memory management (at least I think
this is the problem).
What I'm trying to do is to get the Query related to a select statement,
alter it and produce a new SPI_plan that
On Wed, 2004-09-15 at 09:04, G u i d o B a r o s i o wrote:
> [EMAIL PROTECTED] postgres]$ createlang plpgsql tech_mis
> createlang: language installation failed: ERROR: could not load
> library "/usr/local/pgsql/lib/plpgsql.so":
> /usr/local/pgsql/lib/plpgsql.so: undefined symbol: PG_exception_st
Hi Simon,
Sorry it has taken so long. Among other things, I doubled the controllers
and drives on the system I was testing this on. But now I have some data
against PostgreSQL-8.0beta2.
Here is the test run with archiving enabled:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/1
Tom Lane wrote:
> AFAIR, the only place where these numbers are stored is in
> pg_database.datencoding, so only the server-encoding values are
> frozen in any meaningful sense. You could rearrange the numbers
> currently assigned to client encodings to preserve the range
> property.
Interesting.
G u i d o B a r o s i o wrote:
> Is this ok? Banner version, 8 beta2, version() returns 7.4.2.
The banner shows the psql (client) version, version() shows the server
version.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
[EMAIL PROTECTED] local]$ psql template1
Welcome to psql 8.0.0beta2, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
te
Didn't find a solution for this on the lists, and I am not a yet-brand-new-guru, so...
I ask :)
What about this?
I've found a box (dual Intel(R) Xeon(TM) CPU 2.80GHz) in which to test the beta2.
Trying to cretae proc languages I found this error. I've seen error creating languages
on other b
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Some people have requested to add WIN1250 as an allowed server encoding.
> So far, the order of the encoding numbers determined which ones were
> client-only, so in order not to renumber the encodings, I could only
> come up with the attached ugly
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
(3) The parser must distinguish between two cases when it sees an
unknown word (T_WORD) beginning a statement. The word could be the
beginning of a SQL statement (stmt_execsql in the grammar), such as:
UPDATE ...;
or the na
On Wed, Sep 15, 2004 at 05:02:44PM +0200, Peter Eisentraut wrote:
> Some people have requested to add WIN1250 as an allowed server encoding.
> So far, the order of the encoding numbers determined which ones were
> client-only, so in order not to renumber the encodings, I could only
> come up wi
Neil Conway <[EMAIL PROTECTED]> writes:
> (3) The parser must distinguish between two cases when it sees an
> unknown word (T_WORD) beginning a statement. The word could be the
> beginning of a SQL statement (stmt_execsql in the grammar), such as:
> UPDATE ...;
> or the name of a function in a fu
Some people have requested to add WIN1250 as an allowed server encoding.
So far, the order of the encoding numbers determined which ones were
client-only, so in order not to renumber the encodings, I could only
come up with the attached ugly solution. If no one thinks of a better
one, we'll g
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Question: what is the relevance of the binary protocol, are you trying
> to send/fetch binary data via the command interface?
My understanding of the original post is that DBD::Pg is sitting atop
libpq and wants to keep doing so. So they're going to
On Sep 15, 2004, at 9:43 AM, Chris Dunlop wrote:
Either that, or I'm missing something...
From the SELECT docs ...
A JOIN clause combines two FROM items. Use parentheses if necessary
to determine the order of nesting. In the absence of parentheses,
JOINs nest left-to-right. In any case JOIN
G'day,
There seems to be a kind of statement parsing problem in 7.4.5
(from debian postgresql-7.4.5-3, i386).
Either that, or I'm missing something...
The following script:
--
create table t1 ( foo1 integer, foo2 integer );
cre
Devrim GUNDUZ wrote:
> > Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
> > SELECT ... NOWAIT one. Today I got a request for this; and it was
> > reported that this feature will be used in a huge project.
> >
> > Well, it shouldn't be too much of a patch - just cloning the
> A bit of context here. The perl DBD::Pg developers are trying to
figure
> out
> how to implement prepared queries sanely. As it stands now they're
> basically
> writing off both binary prepared queries and SQL based prepared
queries as
> basically useless. It would be a shame to have a brand new
62 matches
Mail list logo
