Neil Tiffin wrote:
> 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 because the uid
> 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
Tom Lane wrote:
>
> 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 versi
At 11:22 AM -0400 8/7/01, Tom Lane wrote:
>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
>>
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
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, p
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 serv
> > 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 whic
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 wi
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. Thi
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
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
--
> 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 serve
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 (
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
> iden
27;d throw that in.
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian
Sent: August 3, 2001 9:22 AM
To: Tom Lane
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] OID wraparound: summary and proposal
> [EMAIL PROTECTED] (Nathan Myers) write
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > At the same time that we announce support for optional OIDs,
> > we should announce that, in future releases, OIDs will only be
> > guaranteed unique (modulo wraparounds) within a single table.
>
> Seems reasonable --- that will give people notice t
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) is redundant and
slows t
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Hmm there seems to be an assumption that people could
> > know whether they need OID or not for each table.
>
> A good point, and one reason not to make no-OIDs the default. I'm
> envisioning that people will turn off OIDs only fo
On Thu, Aug 02, 2001 at 09:28:18AM +0200, Zeugswetter Andreas SB wrote:
>
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption.
>
> I for one am more concerned about adding additional
> > At the same time that we announce support for optional OIDs,
> > we should announce that, in future releases, OIDs will only be
> > guaranteed unique (modulo wraparounds) within a single table.
... if an appropriate unique constraint is explicitly created.
>
> Seems reasonable --- that wi
Zeugswetter Andreas SB wrote:
>
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption.
>
> I for one am more concerned about adding additional per
> tuple overhead (moving from 32 -> 64b
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The followings are the result of vote which I remember
> well.
FWIW, I changed my vote ;-). I'm not sure what Vadim and Lamar think
at the moment, but I thought you made good arguments.
regards, tom lane
--
Nathan Myers wrote:
>
> On Thu, Aug 02, 2001 at 09:28:18AM +0200, Zeugswetter Andreas SB wrote:
> >
> > > Strangely enough, I've seen no objection to optional OIDs
> > > other than mine. Probably it was my mistake to have formulated
> > > a plan on the flimsy assumption.
> >
> > I for one am more
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Hmm there seems to be an assumption that people could
> know whether they need OID or not for each table.
A good point, and one reason not to make no-OIDs the default. I'm
envisioning that people will turn off OIDs only for tables that they
know will b
> Strangely enough, I've seen no objection to optional OIDs
> other than mine. Probably it was my mistake to have formulated
> a plan on the flimsy assumption.
I for one am more concerned about adding additional per
tuple overhead (moving from 32 -> 64bit) than loosing OID's
on some large tables
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> For input, I see no downside to just
> >> ignoring the incoming OIDs. For output, I can see three reasonable
> >> possibilities:
> >>
> >> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
> >> "do the right thing", but a rather strong
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>
> >> Given Hiroshi's objections, and the likelihood of compatibility problems
> >> for existing applications, I am now thinking that it's not a good idea to
> >> turn off OID generation by default.
>
> > Would
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>
>> Given Hiroshi's objections, and the likelihood of compatibility problems
>> for existing applications, I am now thinking that it's not a good idea to
>> turn off OID generation by default.
> Would OIDs be globally unique or per ta
Tom Lane wrote:
>
> Given Hiroshi's objections, and the likelihood of compatibility problems
> for existing applications, I am now thinking that it's not a good idea to
> turn off OID generation by default. (At least not for 7.2 --- maybe in
> some future release we could change the default.)
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> For input, I see no downside to just
>> ignoring the incoming OIDs. For output, I can see three reasonable
>> possibilities:
>>
>> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
>> "do the right thing", but a rather strong objection is
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> 6. COPY out WITH OIDS will ignore the "WITH OIDS" specification if the
> >> table has no OIDs. (Alternative possibility: raise an error --- is that
> >> better?) COPY in WITH OIDS will silently drop the incoming OID values.
>
> > Obviously, the c
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 6. COPY out WITH OIDS will ignore the "WITH OIDS" specification if the
>> table has no OIDs. (Alternative possibility: raise an error --- is that
>> better?) COPY in WITH OIDS will silently drop the incoming OID values.
> Obviously, the case here is
> Given Hiroshi's objections, and the likelihood of compatibility problems
> for existing applications, I am now thinking that it's not a good idea to
> turn off OID generation by default. (At least not for 7.2 --- maybe in
> some future release we could change the default.)
This seems good. Pe
On Wed, 1 Aug 2001, Tom Lane wrote:
> 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.
>
> Note: there was some di
Given Hiroshi's objections, and the likelihood of compatibility problems
for existing applications, I am now thinking that it's not a good idea to
turn off OID generation by default. (At least not for 7.2 --- maybe in
some future release we could change the default.)
Based on the discussion so f
36 matches
Mail list logo
