thanks
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On 11/16/2004 6:32 AM, Holger Klawitter wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A little bit OT, but:
is there a way of removing duplicate rows in a table without OIDs?
There is still the CTID.
Jan
Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists klawit
On 11/16/2004 4:52 AM, Michael Glaesemann wrote:
On Nov 16, 2004, at 6:42 PM, Peter Eisentraut wrote:
Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
Michael Glaesemann zei:
OIDS are a system level implementation. They are no longer required
(you can make tables without OIDS) and they may go aw
Helps me. Thanks for the clairification.
On Wednesday 17 November 2004 06:49 am, Martijn van Oosterhout saith:
> Just to clarify, there is a difference between OIDs and XIDs. Object
> IDs (OID) are a system assigned field to every row that eventually
> wraps around. If you don't use them in your a
Just to clarify, there is a difference between OIDs and XIDs. Object
IDs (OID) are a system assigned field to every row that eventually
wraps around. If you don't use them in your application you'll hever
really have a problem. The only exception is that statements that
modify structures in the dat
Michael Glaesemann wrote:
On Nov 15, 2004, at 3:52 PM, Jamie Deppeler wrote:
Hi,
I am planning to use OID for referencing as instead PK -->> FK on
this situation would require alot of tables, OID would seen to nice
solution.
My worry with OID's is when i do SQL dump and rebuild the Database
If you have a primary key you can self join the table on the rows that would
define a table as duplicate and delete the one with a higher primary key
field. If the table is related to other tables (ie the pk is an fk in
another table) you have to make sure you update all the rows to point to the
n
> How do you make use of this? It seems like you would need your code to know
> which foreign_oid referred to which table to actually perform the join.
Sorry, wasn't very clear about what it does:
select * from mytable t left join joinme j on t.id = j.foreign_id and
t.tableoid = j.foreign_oid;
Matt <[EMAIL PROTECTED]> writes:
> I ask because I'm currently using them to join a single table to rows in
> arbitrary tables, something like:
>
> +-+
> | JOINME |
> +-+
> | foreign_oid |
> | foreign_id |
> | ... |
> +-+
>
> Where foreign_oid is
--- Joolz <[EMAIL PROTECTED]> wrote:
>
> Thanks.
>
> Btw what's going on on the list??? I seems someone
> is posting a lot
> of obscene nonsense, using my email address. I saw
> this happen
> before with someone else. Is there anything I can do
> about it?
This is the down side of free will.
On Nov 16, 2004, at 11:44 PM, Joolz wrote:
Btw what's going on on the list??? I seems someone is posting a lot
of obscene nonsense, using my email address.
net.kook
I saw this happen
before with someone else. Is there anything I can do about it?
Filter aggressively and be patient. Not a happy situa
Peter Eisentraut zei:
> Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
>> Michael Glaesemann zei:
>> > OIDS are a system level implementation. They are no longer
>> required
>> > (you can make tables without OIDS) and they may go away someday.
>>
>> Out of curiosiry: how will we handle blobs
On Tue, 2004-11-16 at 12:32, Holger Klawitter wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> A little bit OT, but:
> is there a way of removing duplicate rows in a table without OIDs?
>
ALTER TABLE ... ADD COLUMN myoid int;
CREATE TEMP SEQUENCE myoidsequence;
UPDATE ... SET m
Hi,
> > > > OIDS are a system level implementation. They are no longer required
> > > > (you can make tables without OIDS) and they may go away someday.
What about tableoids? Are they from the same generator as row oids (and
hence may suffer wrap-around)? Or are they unique across the db?
I ask
> On Tue, 16 Nov 2004 08:01 pm, Joolz wrote:
> > Michael Glaesemann zei:
> > >
> > > OIDS are a system level implementation. They are no longer required
> > > (you can make tables without OIDS) and they may go away someday.
> >
> > Out of curiosiry: how will we handle blobs once the OID's are gone
On Nov 16, 2004, at 8:32 PM, Holger Klawitter wrote:
A little bit OT, but:
is there a way of removing duplicate rows in a table without OIDs?
One method that I believe works (haven't tried it in a while):
BEGIN;
CREATE TEMP TABLE foo_temp AS
SELECT DISTINCT bar, bat, baz
FROM foo;
TRUNCATE foo;
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A little bit OT, but:
is there a way of removing duplicate rows in a table without OIDs?
Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists klawitter de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Peter Eisentraut wrote:
There are certainly ways to handle this. But no one has seriously proposed
getting rid of OIDs and presented a plan for fixing all the other holes that
move would leave.
Right; I certainly have no intention of trying to remove OIDs any time
soon. However, I _will_ be pro
On Tue, 16 Nov 2004 08:01 pm, Joolz wrote:
> Michael Glaesemann zei:
> >
> > OIDS are a system level implementation. They are no longer required
> > (you can make tables without OIDS) and they may go away someday.
>
> Out of curiosiry: how will we handle blobs once the OID's are gone?
>
I would g
Am Dienstag, 16. November 2004 10:52 schrieb Michael Glaesemann:
> You sound pretty certain. I can imagine there might be a way to handle
> BLOBs without OIDs. I'm not saying that I know what it is, but I
> recognize the possibility.
There are certainly ways to handle this. But no one has serious
On Nov 16, 2004, at 6:42 PM, Peter Eisentraut wrote:
Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
Michael Glaesemann zei:
OIDS are a system level implementation. They are no longer required
(you can make tables without OIDS) and they may go away someday.
Out of curiosiry: how will we handle
Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
> Michael Glaesemann zei:
> > OIDS are a system level implementation. They are no longer required
> > (you can make tables without OIDS) and they may go away someday.
>
> Out of curiosiry: how will we handle blobs once the OID's are gone?
They wo
Michael Glaesemann zei:
>
> OIDS are a system level implementation. They are no longer required
> (you can make tables without OIDS) and they may go away someday.
Out of curiosiry: how will we handle blobs once the OID's are gone?
---(end of broadcast)
On Nov 15, 2004, at 4:05 PM, Michael Glaesemann wrote:
Just add a nice SERIAL column to the tables you want as foreign keys
(and if you have questions about sequences, check the FAQ).
Erg... SERIALs on the tables as primary keys. Integers on tables
referencing the primary key for foreign keys.
M
On Nov 15, 2004, at 3:52 PM, Jamie Deppeler wrote:
Hi,
I am planning to use OID for referencing as instead PK -->> FK on
this situation would require alot of tables, OID would seen to nice
solution.
My worry with OID's is when i do SQL dump and rebuild the Database
will OID will change makin
Hi,
I am planning to use OID for referencing as instead PK -->> FK on
this situation would require alot of tables, OID would seen to nice
solution.
My worry with OID's is when i do SQL dump and rebuild the Database will
OID will change making referencing certain records impossible.
--
J
Mike Nolan <[EMAIL PROTECTED]> writes:
>> You are correct. nextval() is guaranteed never to give the same number
>> (unless setval() were used to reset the sequence value).
> Or unless the sequence wraps around. That's less likely (and less
> dangerous) than having the OID wrap around, but not
On Sat, 23 Oct 2004, Mike Nolan wrote:
> I personally believe that there is value in a database-generated unique
> value like Oracle's ROWID. (Part of what I like about it is that since
> it is a system column it simplifies some application issues, since the
> app never has to worry about that co
> You are correct. nextval() is guaranteed never to give the same number
> (unless setval() were used to reset the sequence value).
Or unless the sequence wraps around. That's less likely (and less
dangerous) than having the OID wrap around, but not impossible.
I personally believe that there
On Sat, 2004-10-23 at 17:46 +0200, Leen Besselink wrote:
> Eddy Macnaghten zei:
> > I think you are correct in not using OIDs, as, firstly, as you point out
> > they are optional, also that they are not neccessarily unique.
> >
>
> I'm sorry Eddy, but you most be mistaken:
>
> Every row in POSTGR
On Sat, 23 Oct 2004, Leen Besselink wrote:
> Eddy Macnaghten zei:
> > I think you are correct in not using OIDs, as, firstly, as you point out
> > they are optional, also that they are not neccessarily unique.
> >
>
> I'm sorry Eddy, but you most be mistaken:
>
> Every row in POSTGRESQL is assigne
On Sat, Oct 23, 2004 at 14:52:31 +0200,
Leen Besselink <[EMAIL PROTECTED]> wrote:
>
> id = nextval ("whatever_id_seq");
> insert into whatever (id, text) values (id, 'something');
>
> Something that works always... better, but you need to know the name of
> the sequence, bummer.
In 8.0 (curren
Eddy Macnaghten zei:
> I think you are correct in not using OIDs, as, firstly, as you point out
> they are optional, also that they are not neccessarily unique.
>
I'm sorry Eddy, but you most be mistaken:
Every row in POSTGRESQL is assigned a unique, normally invisible number
called an object ide
Eddy Macnaghten <[EMAIL PROTECTED]> writes:
> The other thing to be aware of is if a large number of people are
> writing to the database concurrently it can go wrong (any method). That
> is if you insert a record (using nextval for the sequence), then someone
> else quickly inserts a row too bef
I think you are correct in not using OIDs, as, firstly, as you point out
they are optional, also that they are not neccessarily unique.
The use of sequences is an idea, however, why the complication? Why not
simply use a sequence called "mytable_sequence", or "mytable_id" where
"mytable" is the n
Hi pgsql-general,
(all examples are pseudo-code)
We really love PostgreSQL, it's getting better and better, there is just
one thing, something that has always led to some dislike: OID's
I understand why they did it and all, but still.
To make life easier, it's always good to find a general way
> What PG version are you using?
>
> IIRC, in pre-7.1 code, backends allocate OIDs in blocks of 32 (?? more
> or less anyway); so if a backend uses one OID and then exits, you wasted
> 31 OIDs. This does not happen anymore with 7.1, though.
>
> Another possibility is that you're creating lots of
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
>Recently, our OID usage has started to jump dramatically - today, we're
> using ten thousand or more in a few minutes. We're trying to figure out
> just what is using so many, without any luck. Aside from doing a lot of
> inserts (which we don't do
> >Also, when the OID's reach the limit of an int4, if I recall
correctly,
> > they simply wrap around, and things keep working unless you depend on
> > unique OID's. Is that correct?
>
> That's correct.
>
> cheers,
> t.
>
> p.s. and rumor has it that the universe will start shrinking as soon
On Wed, 30 May 2001, Steve Wolfe wrote:
>
> I know that this topic comes up fairly often, so I tried to search the
> archives, but the search engine doesn't appear to have info on messages
> after 1999, so forgive me for repeating this topic.
>
>Recently, our OID usage has started to ju
40 matches
Mail list logo
