Hi Tom and others,
I think the correct solution is not to mess with what's admittedly a
legacy aspect of
our client API. Instead we should invent the INSERT RETURNING and
UPDATE RETURNING
commands that have been discussed repeatedly (see the pghackers archives).
That would
allow people to
Tom Lane wrote:
I seem to recall that there was some special consideration for files
that would conditionally show up in multiple executables. Or were
you going to fix that by having just one .mo file for all the
clients?
The current method is to explicitly register the source file in each
Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
cannot run with 8.0's libpq. Example:
$ LD_LIBRARY_PATH=/home/peter/devel/pg80/pg-install/lib
/home/peter/devel/pg74/pg-install/bin/psql --help
Hello
I have a problem running initdb 8.0.1. I get this error message when I
try to run this command in my system:
---
-bash-2.05b$ /local/opt/postgresql/bin/initdb
The program postgres is needed by initdb but was not found in the
Tom Lane wrote:
Based on this I think we ought to go with the unrolled approach, ie,
we'll create a macro to initialize the fixed fields of fcinfo but fill
in the arg and argisnull arrays with code like what's already in
FunctionCall2:
I agree. The unrolled approach is a good result in most
Mark Cave-Ayland [EMAIL PROTECTED] writes:
Just off the top of my head, would it not be feasible to add a column to
pg_class called lastinsert that points to the OID of the pg_attribute column
to return after an insert?
No. The thing everyone is ignoring here is that the INSERT command tag
Rafael Martinez Guerrero [EMAIL PROTECTED] writes:
If we install the binaries for postgres under /local/opt/postgresql/bin,
initdb in this directory will be a symblink to
/local/store/bbking/.postgresql/ver-8.0.1/opt/postgresql/bin/[EMAIL
PROTECTED]
uxlibc63=20
and=20
Rafael Martinez Guerrero wrote:
Hello
I have a problem running initdb 8.0.1. I get this error message when I
try to run this command in my system:
---
-bash-2.05b$ /local/opt/postgresql/bin/initdb
The program postgres is needed by
Peter Eisentraut [EMAIL PROTECTED] writes:
Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
cannot run with 8.0's libpq.
[ shrug... ] I don't think we've ever guaranteed that anyway. I will
resist
Tom Lane [EMAIL PROTECTED] writes:
How is what you're suggesting more portable?
Well, the driver would be free to implement $sth-last_insert_id() using
whatever proprietary extensions it has available. The non-portableness would
at least be hidden in the driver layer. Switch out the driver and
Martin Pitt [EMAIL PROTECTED] writes:
What would you propose as a solution?
Do nothing. The problem you are raising isn't very serious since
RPM-style installations don't support concurrent installation of
multiple PG versions anyway. That being the case, it doesn't really
matter whether 8.0
Bruce Momjian pgman@candle.pha.pa.us writes:
Added to release checklist:
* Update inet/cidr data types with newest Bind patches
You should also add check for zic database updates.
regards, tom lane
---(end of
Tom Lane wrote:
Paul Vixie [EMAIL PROTECTED] writes:
i have two suggestions. first, look at the rest of the current source file,
in case there are other fixes.
Right, I already grabbed the latest.
second, track changes this source file during
your release engineering process for
Mark Cave-Ayland wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 31 January 2005 16:35
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
(cut)
Judging by the symptoms, you
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How is what you're suggesting more portable?
Well, the driver would be free to implement $sth-last_insert_id() using
whatever proprietary extensions it has available. The non-portableness would
at least be hidden in the
Tom Lane [EMAIL PROTECTED] writes:
INSERT/UPDATE ... RETURNING isn't something a driver can take
advantage
of.
It would require it to modify your statements which it can't do
safely. So
your application would have such non-portable SQL code written into
it.
Switch
databases and your
Allow ASC/DESC direction modifiers for index columns.
Almost every database has this, and it is a pest to have to
write a function for every index column you want descending.
Now, it is not technically difficult (nothing more than compare(x,y)
instead of compare(x,y) to produce the
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote:
His point stands though: if you are accessing Postgres through some kind
of connection-pooling software, currval() cannot be trusted across
transaction boundaries, since the
Dann Corbit [EMAIL PROTECTED] writes:
Allow ASC/DESC direction modifiers for index columns.
We aren't going to do that, because it would be a meaningless concept
for indexes that don't impose a linear sort order (which is to say,
everything except btrees). The concept that actually fits into
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Added to release checklist:
* Update inet/cidr data types with newest Bind patches
You should also add check for zic database updates.
Uh, we already have:
* Update timezone data to match latest zic database (see
Tom Lane wrote:
Martin Pitt [EMAIL PROTECTED] writes:
What would you propose as a solution?
Do nothing. The problem you are raising isn't very serious since
RPM-style installations don't support concurrent installation of
multiple PG versions anyway. That being the case, it doesn't really
Obviously, you cannot create ordering in hash indexes, which is why
nobody else does that either.
The list of relational database systems that offer asc/desc on btree
index files is quite extensive.
The list of relational database systems that do not offer it is:
1. PostgreSQL
2. ?
It will
Peter Eisentraut [EMAIL PROTECTED] writes:
We can rectify the mistake, but then we need to change the SONAME.
That's what it's for.
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
This brings up a point that I think has been discussed before: we
operate on the
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
We can rectify the mistake, but then we need to change the SONAME.
That's what it's for.
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
This brings up a point that I think has been discussed before:
Bruce Momjian pgman@candle.pha.pa.us writes:
According to our RELEASE_CHANGES documentation:
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited to:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
According to our RELEASE_CHANGES documentation:
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited
On Wed, Feb 02, 2005 at 09:50:16AM -0800, Dann Corbit wrote:
Obviously, you cannot create ordering in hash indexes, which is why
nobody else does that either.
The list of relational database systems that offer asc/desc on btree
index files is quite extensive.
How many in that list allow you
Christopher Kings-Lynne wrote:
I notice the CONNECT BY patch has been updated for 8.0:
http://gppl.moonbone.ru/
Seriously, we really need to get this into 8.1. Convert it to the
standard WITH RECURSIVE syntax if necessary...
Yep, we are just waiting for someone to do the work.
--
Tom,
Why is that a problem? The complaint seems about analogous to saying
we should not have groups because you can't REVOKE rights from an
individual user if he has them via a group membership.
Oh, mostly I'm just bitching because I had seeing a new feature I can't
use ;-)
--
Josh Berkus
Bruce Momjian wrote:
The only downside I see to bumping the major
number each time is that the major number could get pretty big. Do
the dynamic library systems handle two-digit library version numbers
properly?
MySQL's client library is at 12, so I don't see a problem.
--
Peter Eisentraut
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How is what you're suggesting more portable?
Well, the driver would be free to implement $sth-last_insert_id() using
whatever proprietary extensions it has available. The
Hello,
Ran into this little gem with a customer today:
This works:
create table foo (foo int not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
pg_dump will correctly dump the table:
CREATE TABLE foo (
foo integer DEFAULT
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How is what you're suggesting more portable?
For postgres it looks like currently it requires you to pass in the
table
and
field might even need a driver-specific hint telling
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How is what you're suggesting more portable?
Well, the driver would be free to implement $sth-last_insert_id() using
whatever proprietary extensions it has available. The non-portableness would
at least be
Greg Stark [EMAIL PROTECTED] writes:
This is from the DBI documentation -- that is, the non-driver-specific
abstract interface documentation.
Returns a value 'identifying' the row just inserted, if possible.
Typically this would be a value assigned by the database server
Joshua D. Drake [EMAIL PROTECTED] writes:
However if you do the following:
create table foo (foo serial not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
This portable function is so unportable that I see no reason to
accept it as precedent.
Hm. Instead of altering the syntax, what slipping in the last
inserted/updated tuple into the PQResult object? Maybe is a protocol
level option? Now everybody gets to use it with minimal muss.
Merlin
create table foo (foo serial not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
expression of a SERIAL column, because it's part of the internal
implementation of
Tom Lane wrote:
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
object.
Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
The Linux conventions for library names, for one,
essentially require us to bump SO_MAJOR_VERSION for every release if
we want to have
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
It is not pilot error if PostgreSQL allows it. There is
nothing illegal about the above commands in their execution.
The pg_dump application should recognize that the object has
changed and react accordingly.
ISTM this is a
According to our RELEASE_CHANGES documentation:
The major version number should be updated whenever the
source of the
library changes to make it binary incompatible. Such
changes include,
but are not limited to:
1. Removing a public function or
a_ogawa [EMAIL PROTECTED] writes:
Tom Lane wrote:
Based on this I think we ought to go with the unrolled approach,
I agree. The unrolled approach is a good result in most environments.
I have committed changes along this line in HEAD and 8_0 branches.
First of all, this macro will be
Peter Eisentraut wrote:
Tom Lane wrote:
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
object.
Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
I am thinking we should up the 8.0.* and 8.1.* releases to have the same
major number, but not make a major
Peter Eisentraut [EMAIL PROTECTED] writes:
... If they don't have
different sonames, then we declare that they are compatible, so it
should be OK to have only the latest version installed. That requires
us to stay honest with the sonames, but it does not require us to
increase the
Hi list,
Attached for your perusal, unicode versions of upper/lower, that work
independent of locale except for the following languages:
Turkish, Azeri, and Lithuanian.
There are 15 locale specific cases in total not covered.
--
John Hansen [EMAIL PROTECTED]
GeekNET
collate.tar.gz
Alvaro Herrera wrote:
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
It is not pilot error if PostgreSQL allows it. There is
nothing illegal about the above commands in their execution.
The pg_dump application should recognize that the object has
changed and react accordingly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Merlin Moncur wrote:
That is a shortcoming of the DBD::pg driver which really should be
returning a key (comprised of columns, some or none of which may be
defaulted by the server).
Actually, the spec comes from DBI, not DBD::Pg, and is
Attempts to return the id of the last value to be inserted into a table.
You can either provide a sequence name (preferred) or provide a table
name with optional schema. The $catalog and $field arguments are always
ignored.
The current value of the sequence is returned by a call to the
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
... If they don't have
different sonames, then we declare that they are compatible, so it
should be OK to have only the latest version installed. That requires
us to stay honest with the sonames, but it does not require us to
Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
object.
Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
I am thinking we should up the 8.0.* and 8.1.* releases to have the same
major
Bruce Momjian pgman@candle.pha.pa.us writes:
In fact by upping the major every time will 7.2 clients automatically use
the 7.3 libpq or will they have to be relinked?
If you do not bump the soname then 7.2 clients will automatically immediately
start using the new library when it's installed.
This behavior seems inconsistent:
neilc=# create table abc (a int, b int);
CREATE TABLE
neilc=# create function foo_abc() returns setof abc as 'select * from
abc' language sql;
CREATE FUNCTION
neilc=# insert into abc values (5, 10);
INSERT 17234 1
neilc=# insert into abc values (10, 20);
INSERT
Neil Conway [EMAIL PROTECTED] writes:
neilc=# select a, (select * from abc) from abc;
ERROR: subquery must return only one column
Is there a reason we can't treat a subselect in the target list as
returning a composite type?
Given the 8.0 infrastructure for unnamed record types it might be
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
neilc=# select a, (select * from abc) from abc;
ERROR: subquery must return only one column
Is there a reason we can't treat a subselect in the target list as
returning a composite type?
Given
Joshua D. Drake [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
ISTM this is a bug, but it's not clear to me what is the solution.
I can think of two:
1. Changing the default is forbidden
2. When the default is changed, the dependency on the sequence is
dropped, and the sequence itself is
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
The syntax you are showing is designed
to return a scalar. It will (and should) barf on multiple rows as well
as multiple columns.
I don't understand; the example I posted is of an SRF that returns
multiple rows of multiple columns, which is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This suffers from the same problems that currval does when using
connection pools tho.
I still don't see this as much of a real world problem however,
more of a doctor, it hurts when I do this variety. As the DBD::Pg docs
point out, you should
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
The syntax you are showing is designed
to return a scalar. It will (and should) barf on multiple rows as well
as multiple columns.
I don't understand; the example I posted is of an SRF that returns
Hi!
(sorry for the additional addresses; I'm not subscribed to -hackers,
so my mail will last a while until it arrives there).
Tom Lane [2005-02-02 11:07 -0500]:
Peter Eisentraut [EMAIL PROTECTED] writes:
Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola [EMAIL PROTECTED] writes:
|
|my warning was due the fact that in the docs is written nowhere this
|drawback.
|
|
| The SELECT reference page already says that the output rows are computed
| before applying ORDER BY or
uhmm,...
Forgot to change the copyright.
Please accept this under the same terms as postgresql itself.
... John
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
I tried asking on [EMAIL PROTECTED], and Mark
Cave-Ayland suggested
I ask you folks.
I installed PostGIS, which appeared to work just fine. The I
installed contrib/btree_gist, and since then I've had issues.
Some background: My postgres setup is on Red Hat linux, installed
from RPMs. It is a
Following belows thread
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg43381.html
I am experiencing the same problem on a brand new, extremely fresh, solaris 5.9
and PostgreSQL 7.4.6 box.
As expected, the problem was solved when passing the -d [1-5] to the
postmaster. But... I
Hi Tom!
Tom Lane [2005-02-02 12:01 -0500]:
Martin Pitt [EMAIL PROTECTED] writes:
What would you propose as a solution?
Do nothing.
That's unfortunately not an option.
The problem you are raising isn't very serious since
RPM-style installations don't support concurrent installation of
Robin Chauhan [EMAIL PROTECTED] writes:
I installed PostGIS, which appeared to work just fine. The I
installed contrib/btree_gist, and since then I've had issues.
PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
Would you have any advice for me?
Try a more modern
G u i d o B a r o s i o [EMAIL PROTECTED] writes:
Following belows thread
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg43381.html
I am experiencing the same problem on a brand new, extremely fresh, solaris
5.9 and PostgreSQL 7.4.6 box.
As expected, the problem was solved
On Wed, Feb 02, 2005 at 03:49:59PM -0800, Joshua D. Drake wrote:
Alvaro Herrera wrote:
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
It is not pilot error if PostgreSQL allows it. There is
nothing illegal about the above commands in their execution.
The pg_dump
3. When the default is changed, the dependency is updated
to reflect the new sequence. The old sequence is left intact
as an independent object.
What exactly is the use-case of that (or any other manipulation of a
serial column's default)? There is no point that I can see in just
rolling
Bruce Momjian wrote:
Uh, if we bump up the major library version in 8.0.X, will that
require 8.0.0 user applications to be recompiled?
No, they just keep using the old library.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Following some advice from Intel,
http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/threading
/20469.htm?page=2
I'm looking at whether the LWLock data structures may be within the same
cache line.
Intel uses 128 byte cache lines on its high end processors.
slru.c uses BUFFERALIGN
A few thoughts on LWLock data structures...
In lwlock.c we hold a list of lwlocks held:
held_lwlocks[MAX_SIMUL_LWLOCKS]
where
#define MAX_SIMUL_LWLOCKS 100
The code for LWLockRelease assumes that the last acquired lock will
always be the first one to be released, and uses an O(N) loop to
71 matches
Mail list logo
