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
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 code?
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 );
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
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 need
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
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 function
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 with
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
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
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
[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
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
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. I
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:
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_stack
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
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 think
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
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
-
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
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
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
libpq and wants
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
-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 Stark [EMAIL
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.
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 seems fairly
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 what the
-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 Lane
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
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:
Gaetano Mendola wrote:
python -c from distutils import * /dev/null 21 || (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 works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Conway wrote:
| Gaetano Mendola wrote:
|
| python -c from distutils import * /dev/null 21 || (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
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
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
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.
Thanks very much.
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 what
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
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
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
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.
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 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
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
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.
It
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
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:
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.
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
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 Emeritus
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.
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.
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. The
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 gets the
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
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
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
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
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
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 me.
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?
Is
61 matches
Mail list logo
