Based on the discussion so far, here is an attempt to flesh out the
details of what to do with OIDs for 7.2:
1. Add an optional clause WITH OIDS or WITHOUT OIDS to CREATE TABLE.
The default behavior will be WITH OIDS.
What about having an additional Oid generator which solely serves for
I'm missing an email here somewhere, and apologize ... I'm just getting my
mailboxes back in order now after moving to a dial-up link vs high speed
(moved to a non-high-speed neighboorhood *sigh*) ...
Tom, can you resend that list of changes you sent to me earlier?
On Tue, 7 Aug 2001, Justin
Marc G. Fournier [EMAIL PROTECTED] writes:
(moved to a non-high-speed neighboorhood *sigh*) ...
Ugh :-(
Tom, can you resend that list of changes you sent to me earlier?
Attached is the updated list. Note there are a couple of changes listed
that aren't actually in REL7_1_STABLE yet, but if
Tom,
If we have WITH NOOID, why not having a WITH OID32 and WITH OID64 (or
something of a sort)
as well (being OID32 the default and OID an alias to it)?
The last would not be available on some systems
(who will use a system that does not support long long as a database
server anyway?)
The
Fernando Nasser [EMAIL PROTECTED] writes:
The wire protocol will always handle the (tableoid) long form,
I think you are handwaving away what is precisely the most painful
aspect. To allow 64-bit type OIDs in the wire protocol, we must
(a) have a protocol version jump, and (b) force all
Hi,
Accidentally I've ran out of disk space during intensive database write
operations. At the begining the backend went to recovery mode a few times,
and continued the work, but finally it has terribly died
( Segfault at backend/utils/mmgr/mcxt.c 222 )
After this event, the recovery
Meszaros Attila [EMAIL PROTECTED] writes:
Accidentally I've ran out of disk space during intensive database write
operations. At the begining the backend went to recovery mode a few times,
and continued the work, but finally it has terribly died
( Segfault at backend/utils/mmgr/mcxt.c
On Tue, 7 Aug 2001, Dave Cramer wrote:
This came into the jdbc list
Apparently bigint is not really 8 bytes???
I test this out with psql
test=# create table testbigint (id serial, fp0 int8);
NOTICE: CREATE TABLE will create implicit sequence 'testbigint_id_seq'
for SERIAL column
Dave Cramer writes:
Apparently bigint is not really 8 bytes???
It's sort of 7.999 bytes.
test=# update testbigint set fp0 = -9223372036854775808 where id = 1;
ERROR: int8 value out of range: -9223372036854775808
This is a bug in the int8 value parser. While it reads the string it
always
On Mon, 6 Aug 2001, Tom Lane wrote:
Giles Lean [EMAIL PROTECTED] writes:
Implementations of strxfrm() that I've looked at have had result data
that is three or four times larger than then input string -- quite a
penalty in some situations.
Especially so given that we don't have TOAST
Hi,
please apply patch to current CVS which implements:
1. null-safe interface to GiST
(as proposed in http://fts.postgresql.org/db/mw/msg.html?mid=1028327)
2. support for 'pass-by-value' arguments - to test this
we used special opclass for int4 with values in range [0-2^15]
More
On Tue, 7 Aug 2001, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I don't think my patch against recent sources would apply cleanly to
older ones, and I didn't run the regression against it, but it seemed
to work, and is only a two line change in current source.
This patch
Stephan Szabo [EMAIL PROTECTED] writes:
I don't think my patch against recent sources would apply cleanly to
older ones, and I didn't run the regression against it, but it seemed
to work, and is only a two line change in current source.
This patch needs more work. You are assuming that
On Mon, Aug 06, 2001 at 06:00:40PM +0200, Peter Eisentraut wrote:
Karel Zak writes:
$ make install prefix=/home/PG_DEVEL/X/
cp: cannot create regular file
/usr/lib/postgresql/share/locale/de/LC_MESSAGES/#
I have fixed this. Note, however, that this probably won't do what you
want
Tom Lane wrote:
If OID remains at 4 bytes then this still isn't very satisfactory for
tables that are likely to have more than 4 billion INSERTs in their
lifetime. However, rather than imposing the cost of 8-byte OIDs
everywhere, I'd be inclined to say that people who need unique
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Am I being overly simplistic?
Yes. For one thing, Relation structs are *not* shared, nor even
persistent (the relcache will happily discard them).
Will it be easier to make Relation shared and persistent or creating
a new shared structure
On Mon, 6 Aug 2001, Tom Lane wrote:
* How should one invoke nextval() and friends on such a sequence?
Perhaps we could allow people to write nextval(sequencename) and/or
sequencename.nextval, which would expose the sequence object to the
parser so that datatype overloading could occur.
I'm
Neil Tiffin wrote:
I would just like to comment that for our project, GNU Enterprise, we
use our own 128 bit object ID that is unique (UUID) for every row in
all tables.
It seems to me, without having looked into it, that having both a
PostgreSQL UID and our own 128 bit objectid (UUID)
Karel Zak writes:
Yes, you are right. But make install prefix=... can be used for
package building if you want install all to some temp directory and
compress it.
In that case it's much better to use make install DESTDIR=
--
Peter Eisentraut [EMAIL PROTECTED]
Hannu Krosing [EMAIL PROTECTED] writes:
I guess that the change of OID from 4 to 8 bytes could be carried out
as a compile time option ?
Not unless you like the notion that the wire protocol depends on a
compile time option.
regards, tom lane
Hannu Krosing [EMAIL PROTECTED] writes:
Will it be easier to make Relation shared and persistent or creating
a new shared structure that has just a counter+lock for each
relation oid ?
The latter. Relation (by which I mean a whole relcache entry with all
its subsidiary structure, not only
On Tue, 7 Aug 2001, Tom Lane wrote:
I'm not worried about the size of the return type of
a sequence, but I like the idea of Oracle-compatible
seq.nextval syntax.
I didn't realize we had any Oracle-compatibility issues here. What
exactly does Oracle's sequence facility look like?
It's
At 10:09 AM +0500 8/7/01, Hannu Krosing wrote:
Neil Tiffin wrote:
I would just like to comment that for our project, GNU Enterprise, we
use our own 128 bit object ID that is unique (UUID) for every row in
all tables.
It seems to me, without having looked into it, that having both a
Neil Tiffin [EMAIL PROTECTED] writes:
I have not even considered multiple database servers running
different database, which is our design goal. In this case we would
like to have a slimmed down (and blazingly fast) PostgreSQL server in
which we manage the uid in our middleware. This is
Based on the discussion so far, here is an attempt to flesh out the
details of what to do with OIDs for 7.2:
1. Add an optional clause WITH OIDS or WITHOUT OIDS to CREATE TABLE.
The default behavior will be WITH OIDS.
What about having an additional Oid generator which solely serves
Oliver Elphick [EMAIL PROTECTED] writes:
This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!
So if you have a patch to do that, go ahead.
Sounds
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I guess that the change of OID from 4 to 8 bytes could be carried out
as a compile time option ?
Not unless you like the notion that the wire protocol depends on a
compile time option.
That could be a separate option, perhaps
Oracle PL/SQL supports a very convenient feature in which you can say
something like
DECLARE
CURSUR cur IS SELECT * FROM RECORD;
BEGIN
OPEN cur;
UPDATE record SET field = value WHERE CURRENT OF cur;
CLOSE cur;
END
We have cursors in the development version of PL/pgSQL, but
Bruce Momjian [EMAIL PROTECTED] writes:
This is a very interesting idea. Have two oid counters, one for system
tables and another for user tables. It isolates problems with oid
wraparound caused by large user tables.
Well, it'd keep user-space wraparound from affecting the system tables,
Oliver Elphick [EMAIL PROTECTED] writes:
This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!
So if you have a patch to do that, go ahead.
Sounds great.
config.guess now supports OpenUNIX 8, AIX 5, HPUX on IA64, and Linux on
PPC64. Enjoy.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Curious if anyone has done any work on client side connection pooling
recently? I'm thinking pooling multiplexed against transaction commits?
AZ
---(end of broadcast)---
TIP 6: Have you searched our list archives?
August Zajonc [EMAIL PROTECTED] writes:
Curious if anyone has done any work on client side connection pooling
recently? I'm thinking pooling multiplexed against transaction commits?
^^^
What does this phrase mean exactly?
Ian Lance Taylor [EMAIL PROTECTED] writes:
Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
My question now is: if there is no OID, is there any comparable way to
implement CURRENT OF cursor? Basically what is needed is some way to
identify a particular row between a
This came into the jdbc list
Apparently bigint is not really 8 bytes???
I test this out with psql
test=# create table testbigint (id serial, fp0 int8);
NOTICE: CREATE TABLE will create implicit sequence 'testbigint_id_seq'
for SERIAL column 'testbigint.id'
NOTICE: CREATE TABLE/UNIQUE will
If we decide to release 7.1.3 I'd like to see our patch for
contrib/intarray too.
Oleg
On Tue, 7 Aug 2001, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
(moved to a non-high-speed neighboorhood *sigh*) ...
Ugh :-(
Tom, can you resend that list of changes you sent to
Well, it'd keep user-space wraparound from affecting the system tables,
but given that the system tables have adequate defenses already (ie,
unique indexes) I'm not sure that there's any point. It'd not improve
the picture for user-table OID uniqueness by any measurable degree.
But from the
August Zajonc [EMAIL PROTECTED] writes:
One possible pooling model is to have a bunch of worker connections opened
to the pgsql instance. Then as sql statements arrive the they are routed
through an available connection that is open but not doing any work. So 100
inbound connection may be
hello all
Anyone knows a way to get the machine that execute the query?
thanks ...
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Curious if anyone has done any work on client side connection pooling
recently? I'm thinking pooling multiplexed against transaction
commits?
I did some work on an abstracted DB API (supports PostgreSQL, Oracle and
MySQL natively), with pooling and auto reconnect which I'd be happy to send
Most pooling is in essense a form of multiplexing. For transactions this can
be a bad thing.
10 connections - pooler - 2 worker connections
Incoming connection #1 (I1) issues BEGIN WORK
I1 statement passed to outgoing #1 - O1
I2 and I3 statements flow through to - O2
I4 statement UPDATE
Tom Lane wrote:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
My question now is: if there is no OID, is there any comparable way to
implement CURRENT OF cursor? Basically what is needed is some way to
identify a
Hiroshi Inoue [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
My question now is: if there is no OID, is there any comparable way to
implement CURRENT OF cursor? Basically what is needed is
Ian Lance Taylor wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
My question now is: if there is no OID, is there any comparable way to
implement CURRENT OF cursor?
Hiroshi Inoue [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
My question now is: if there is no OID, is there any comparable way to
implement CURRENT OF cursor? Basically what is
Ian Lance Taylor wrote:
[snip]
Yes TID is available and I introduced Tid Scan in order
to support this kind of implementation. However there
are some notices.
1) Is *FOR UPDATE* cursor allowed in PL/pgSQL ?
(It doesn't seem easy for me).
No, it is not supported
46 matches
Mail list logo
