>> I see that all these issues have been fixed and committed by Tom via
>> git commitid: 281a724d on 6th June, 2008. Was wondering why this fix
>> is not in these supported branches like 8.3.13 for example. Kinda
>> confused..
>
> We don't usually back-patch such large changes.
Oh ok. Thanks.
Reg
On Thu, Mar 3, 2011 at 6:09 AM, Nikhil Sontakke
wrote:
> I see that all these issues have been fixed and committed by Tom via
> git commitid: 281a724d on 6th June, 2008. Was wondering why this fix
> is not in these supported branches like 8.3.13 for example. Kinda
> confused..
We don't usually ba
Hi,
Am referring to the following conversation:
http://archives.postgresql.org/pgsql-bugs/2007-12/msg00190.php
To summarize, in 8.3.x due to improper locking and concurrency issues
in the DROP OBJECT codepath, for example if one tries to drop an index
while dropping the table from another sessio
On Fri, Jan 14, 2011 at 09:39, Joel Jacobson wrote:
> 2011/1/12 Alvaro Herrera :
>> I think this code should live in the Wiki somewhere:
>> http://wiki.postgresql.org/wiki/Snippets
>
> This file contains only the relevant remapping of pg_depend, folding
> the internal linkages properly:
>
> https:
2011/1/12 Alvaro Herrera :
> I think this code should live in the Wiki somewhere:
> http://wiki.postgresql.org/wiki/Snippets
This file contains only the relevant remapping of pg_depend, folding
the internal linkages properly:
https://github.com/gluefinance/pov/blob/master/sql/schema/pov/views/pg_
2011/1/13 David Fetter :
> Please put a self-contained example on the snippets page, and please
> also to check that it actually runs before doing so. You'd mangled
> some aliases in the query you sent, which leads me to believe you
> hadn't actually tried running it.
I actually hadn't really sol
On Wed, Jan 12, 2011 at 09:09:31PM +0100, Joel Jacobson wrote:
> (sorry for top posting,
No worries.
> iPhone + drunk)
A dangerous combination indeed. I hear water, NSAIDs and time can
help with the hangover ;)
> pg_depend_before is a select * from pg_depend before creating the
> test db model
(sorry for top posting, iPhone + drunk)
pg_depend_before is a select * from pg_depend before creating the test db model
Sent from my iPhone
On 12 jan 2011, at 20:36, David Fetter wrote:
> On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
>> 2011/1/12 Tom Lane :
>>> I've sometimes
On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
> 2011/1/12 Tom Lane :
> > I've sometimes found it useful to think of internal dependencies as
> > acting like normal dependencies pointing in the other direction.
> > I'm not sure that would do much to solve your problem, but it might
Excerpts from Joel Jacobson's message of mié ene 12 16:06:24 -0300 2011:
> The query below can both produce a DOT-format graph and a tsort of the
> creatable order of objects:
>
> WITH
> NewObjectOids AS (
> SELECT * FROM pg_depend WHERE deptype <> 'p'
> EXCEPT
> SELECT * FROM pg_depe
On Wed, Jan 12, 2011 at 2:06 PM, Joel Jacobson wrote:
> Tom, you are a genious! No, seriously, I mean it, this is awesome, it
> worked! YES! You totally saved my day! Thank you! Finally! I'm so
> happy! :-) :-) :-)
Hey, guys, I think it worked...!
--
Robert Haas
EnterpriseDB: http://www.enter
Joel Jacobson writes:
> 2011/1/12 Tom Lane :
>> This isn't particularly *useful*, maybe, but it's hardly "impossible".
>> And if we analyzed function dependencies in any detail, circular
>> dependencies among functions would be possible (and useful).
> Thanks Tom for clarifying, this makes me eve
2011/1/12 Tom Lane :
> This isn't particularly *useful*, maybe, but it's hardly "impossible".
> And if we analyzed function dependencies in any detail, circular
> dependencies among functions would be possible (and useful).
Thanks Tom for clarifying, this makes me even more motivated into
implemen
Joel Jacobson writes:
> Also, circular dependencies seems impossible for some object classes,
> such as functions, views, constraints and triggers.
regression=# create table tt(f1 int, f2 int);
CREATE TABLE
regression=# create view v1 as select * from tt;
CREATE VIEW
regression=# create view v2 a
2011/1/12 Alvaro Herrera :
> FWIW this idea fails when you consider stuff such as circular foreign
> keys (and I suppose there are other, more common cases). If you really
> want something general you need to break those apart. (This is the
> explanation for the “break the loop” code in pg_dump I
Excerpts from Joel Jacobson's message of mié ene 12 07:07:35 -0300 2011:
> The automatically created objects, such as primary key indexes,
> constraints and triggers, have been ignored in this graph, as they are
> implicitly created when creating the "base objects".
FWIW this idea fails when you
2011/1/12 Florian Pflug :
> I suggest you try to node-folding strategy and see how far it gets you.
Good suggestion! :-) That's exactly what I've been trying to do, but
failed miserably :-(
I have written a thorough description of my problem and put it on my github:
https://github.com/gluefinanc
On Jan11, 2011, at 23:55 , Joel Jacobson wrote:
> 2011/1/11 Florian Pflug :
>> Could you give an example of the kind of trouble you're experiencing trying
>> to use a topological sort?
>
> Let's say you have a table t and a view v.
> The view v is defined as select * from t;
> If we put all object
2011/1/11 Florian Pflug :
> Could you give an example of the kind of trouble you're experiencing trying
> to use a topological sort?
Let's say you have a table t and a view v.
The view v is defined as select * from t;
If we put all objects in a tree, with the public schema as the root,
both v and
On Jan11, 2011, at 16:54 , Joel Jacobson wrote:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
> The 'a' and 'i' deptype really makes it hard to figure out the
> dependency order, a topological sort does not work.
Could you give an example of the kind of trou
Joel Jacobson writes:
> I need to figure out the order of creation of all objects, not just
> the dependencies for a single object.
In that case try pg_dump's pg_dump_sort.c. You will never get "the"
order of creation of objects, because that isn't tracked; but you can
find out what a safe order
2011/1/11 Tom Lane :
> Try reading the code in src/backend/catalog/dependency.c.
I've tried but failed to figure it out anyway. The focus in
dependency.c is to find out dependencies of a given object.
What I want to do is something slighly different.
I need to figure out the order of creation of a
Joel Jacobson writes:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
Try reading the code in src/backend/catalog/dependency.c.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Has anyone written a in-depth description on how to traverse the pg_depend tree?
The 'a' and 'i' deptype really makes it hard to figure out the
dependency order, a topological sort does not work.
My latest attempt involved trying to group by all objects connected to
each other via deptype 'a' or '
> -Original Message-
> Zeugswetter Andreas SB
>
> > As I mentioned already I'm implementing updatable cursors
> > in ODBC and have half done it. If OIDs would be optional
> > my trial loses its validity but I would never try another
> > implementation.
>
> But how can you do that ? The oi
On Thursday 19 July 2001 06:08, you wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness. It could be added at table creation time
> or from ALTER TABLEL ADD. It seems we just use them too mu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What about moving the oid column out of the tuple header. This saves 4
> bytes in the header in cases where there is no oid on the table.
No it doesn't --- at least not on machines where MAXALIGN is eight
bytes.
I don't think this is worth the trouble
> As I mentioned already I'm implementing updatable cursors
> in ODBC and have half done it. If OIDs would be optional
> my trial loses its validity but I would never try another
> implementation.
But how can you do that ? The oid index is only created by
the dba for specific tables, thus your u
Tom mentioned what should be stored in the OID system column if no oid's
are in the table. He also mentioned that he doesn't want a
variable-length tuple header so will always have an oid system column.
What about moving the oid column out of the tuple header. This saves 4
bytes in the header i
On Fri, 20 Jul 2001, Hiroshi Inoue wrote:
> Bill Studenmund wrote:
> >
> > "How does postgres know that the new table a is sufficiently like the old
> > table that it should be used?"
> >
> > By making the reattachment automatic, you are saying that once we make an
> > object of a given name an
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Could you use CTID instead of OID?
>
> > I am using both.
> > TIDs for fast access and OIDs for identification.
> > Unfortunately TIDs are transient and they aren't
> > that reliable as for identification.
>
>
On Fri, Jul 20, 2001 at 08:45:05AM +0900, Hiroshi Inoue wrote:
>
> It doesn't seem preferable that the default(unadorned) DROP
> allows reattachement after the DROP. The default(unadorned) DROP
> should be the same as DROP RESTRICT(or CASCADE because the current
> behabior is halfway CASCADE?). H
Bill Studenmund wrote:
>
> On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
>
> > > This step I disagree with. Well, I disagree with the automated aspect
> of
> > > the update. How does postgres know that the new table a is sufficiently
> > > like the old table that it should be used? A way the DBA coul
On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
> > This step I disagree with. Well, I disagree with the automated aspect
of
> > the update. How does postgres know that the new table a is sufficiently
> > like the old table that it should be used? A way the DBA could say, "yeah,
> > restablish that," w
Philip Warner <[EMAIL PROTECTED]> writes:
> At 00:00 19/07/01 -0400, Tom Lane wrote:
>> INSERT INTO foo ... RETURNING x,y,z,...
> That would have been me; at the time we also talked about
> UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
> {[Old.|New.]Attr,...}
Hm. I'm less exci
J-P wrote:
> > I need to create a new system table like pg_log to
> > implement a replication scheme. The big problem is
> how
> > I could get an OID for it, a unique OID that is
> > reserved for that table???
Hiroshi Inoue wrote:
>
>
> Do you need the following ?
>
> visco=# select oid from p
> Yes, nowhere near, and yes. Sequence objects require disk I/O to
> update; the OID counter essentially lives in shared memory, and can
> be bumped for the price of a spinlock access.
Sequences also cache values (32 afair) - ie one log record is required
for 32 nextval-s. Sequence' data file is
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Could you use CTID instead of OID?
> I am using both.
> TIDs for fast access and OIDs for identification.
> Unfortunately TIDs are transient and they aren't
> that reliable as for identification.
Hmm ... within a transaction I think
At 12:37 18/07/01 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> At 11:38 18/07/01 -0400, Tom Lane wrote:
>>> I'd just make the dependency be from view_a to a and keep things
>>> simple. What's so wrong with recompiling the view for *every* change
>>> of the underlying table
>>>Bruce Momjian said:
[...]
> > No, we won't, because OID wrap is an issue already for any long-uptime
> > installation. (64-bit XIDs are not a real practical answer either,
> > btw.)
>
> Have we had a wraparound yet?
Just for the record, I had an OID overflow on production database (most
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > As I mentioned already I'm implementing updatable cursors
> > in ODBC and have half done it. If OIDs would be optional
> > my trial loses its validity but I would never try another
> > implementation.
>
> Could you use CTID instead
At 00:00 19/07/01 -0400, Tom Lane wrote:
>that someone (maybe Larry R? I forget now) proposed before:
>
> INSERT INTO foo ... RETURNING x,y,z,...
>
That would have been me; at the time we also talked about
UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
{[Old.|New.]Attr,...
Tom Lane wrote:
>Lamar Owen <[EMAIL PROTECTED]> writes:
>
>>
>>
>
>
>
>Another possibility, given that any app using a feature like this is
>nonportable anyway, is to extend the INSERT statement along the lines
>that someone (maybe Larry R? I forget now) proposed before:
>
> INS
On Wednesday 18 July 2001 07:49 pm, Tom Lane wrote:
> I don't think we should discourage use of OIDs quite as vigorously
> as you propose ;-).
Just playing devil's advocate. As I said, I am one who is using OID's in a
client now but who is willing to forgo that feature for large-system
sta
On Thursday 19 July 2001 12:00 am, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > However, the utility of INSERT returning a unique identifier to the
> > inserted row needs to be addressed -- I would prefer it return the
> Another possibility, given that any app using a feature like
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> As I mentioned already I'm implementing updatable cursors
> in ODBC and have half done it. If OIDs would be optional
> my trial loses its validity but I would never try another
> implementation.
Could you use CTID instead of OID?
Lamar Owen <[EMAIL PROTECTED]> writes:
> However, the utility of INSERT returning a unique identifier to the
> inserted row needs to be addressed -- I would prefer it return the
> defined PRIMARY KEY value for the tuple just inserted, if a PRIMARY
> KEY is defined. If no PRIMARY KEY is defined, r
I wrote:
>
> Tom Lane wrote:
> >
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > I don't love current OIDs. However they have lived in PostgreSQL's
> > > world too long and few people have pointed out that there's no magic
> > > around OIDs. I agree to change OIDs to be per class but strongly
Bill Studenmund wrote:
>
> On Wed, 18 Jul 2001, Hiroshi Inoue wrote:
>
> > Oops I made a mistake.
> > Reference name is needed not an object name,
> > i.e
> > object relid
> > object oid
> > relerence relid
> > reference oid
> > reference name
> >
> > create table a
>> What's wrong with 64-bit oids (except extra 4bytes)?
> Portability, mostly.
Oh, there's one other small problem: breaking the on-the-wire protocol.
We send OIDs as column datatype identifiers, so an 8-byte-OID backend
would not interoperate with clients that didn't also think OID is 8
bytes.
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> What about pg_log? It will easily become a huge file. Currently the
> only solution is re-installing whole database, that is apparently
> unacceptable for very big installation like 1TB.
That's part of the XID wraparound issue, which is a separate
discus
From: Tom Lane <[EMAIL PROTECTED]>
Subject: OID wraparound (was Re: [HACKERS] pg_depend)
Date: Wed, 18 Jul 2001 13:52:45 -0400
Message-ID: <[EMAIL PROTECTED]>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yikes, I am not sure we are ready to make oids optional.
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
> >>
> >> Like what?
>
> > Depends what other system tables you are intending to remove oid's for?
>
> Nothing that requires a description ;-)
You are a sly on
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.
Like what?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe command
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What do we do with other columns that need descriptions and don't have
> oid column.
>>
>> Like what?
> Depends what other system tables you are intending to remove oid's for?
Nothing that requires a description ;-)
regards, t
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I don't love current OIDs. However they have lived in PostgreSQL's
> > world too long and few people have pointed out that there's no magic
> > around OIDs. I agree to change OIDs to be per class but strongly
> > object to let OIDs
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What do we do with other columns that need descriptions and don't have
> > oid column.
>
> Like what?
Depends what other system tables you are intending to remove oid's for?
--
Bruce Momjian| http://candle.pha.pa.us
[
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
>> My thought is to make OID generation optional on a per-table basis, and
>> disable it on system tables that don't need unique OIDs. (OID would
>> read as NULL on any row for which an OID
Bruce Momjian wrote:
>
> > > If you want to make oids optional on user tables,
> > > we can vote on that.
> >
> > Let's vote. I'm proposing optional oids for 2-3 years,
> > so you know how I'll vote -:)
>
> OK, we need to vote on whether Oid's are optional, and whether we can
> have them not crea
> >> I meant we use them in many cases to link entries, and in
> >> pg_description for descriptions and lots of other things
> >> that may use them in the future for system table use.
>
> pg_description is a point I hadn't thought about --- it uses OIDs
> to refer to pg_attribute entries. Howeve
Lamar Owen <[EMAIL PROTECTED]> writes:
> Now for a question: OID creation seems to be a low-overhead task. Is the
> creation of SERIAL PRIMARY KEY values as efficient? Or will we be shooting
> ourselves in the performance foot if frequently-accessed system tables go
> from OID usage to SERIAL
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Remember most pg_description comments are not on column but on functions
> and stuff. That attributenumber is not going to apply there.
Sure, it'd just be zero for non-column items.
regards, tom lane
--
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I don't love current OIDs. However they have lived in PostgreSQL's
> world too long and few people have pointed out that there's no magic
> around OIDs. I agree to change OIDs to be per class but strongly
> object to let OIDs optional.
Uh ... what? I d
On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
>
> My thought is to make OID generation optional on a per-table basis, and
> disable it on system tables
ot; <[EMAIL PROTECTED]>
Cc: "Lamar Owen" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 5:06 PM
Subject: Re: OID wraparound (was Re: [HACKERS] pg_depend)
&g
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Remember most pg_description comments are not on column but on functions
> > and stuff. That attributenumber is not going to apply there.
>
> Sure, it'd just be zero for non-column items.
What do we do with other columns that need descriptions and
>> I meant we use them in many cases to link entries, and in
>> pg_description for descriptions and lots of other things
>> that may use them in the future for system table use.
pg_description is a point I hadn't thought about --- it uses OIDs
to refer to pg_attribute entries. However, pg_descri
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness.
Clearly, certain system tables *must* have OIDs --- pg_class, pg_type,
pg_operator, etc --- because we use those OIDs to refer to objects.
These are e
[trimmed cc:list]
On Wednesday 18 July 2001 17:09, Bruce Momjian wrote:
> OK, we need to vote on whether Oid's are optional, and whether we can
> have them not created by default.
[All the below IMHO]
OID's should be optional.
System tables that absolutely have to have OIDs may keep them.
No n
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Maybe ctid needs to be documented better?
I think it's documented about as well as OID is, actually --- see
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/sql-syntax-columns.html
which AFAIR is the only formal documentation of any of th
>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/18/01, 4:32:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
OID wraparound (was Re: [HACKERS] pg_depend) :
> Bruce Momjian
> OK, we need to vote on whether Oid's are optional,
> and whether we can have them not created by default.
Optional OIDs: YES
No OIDs by default: YES
> > > However, OID's keep our system tables together.
> >
> > How?! If we want to find function with oid X we query
> > pg_proc, if we want
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Also, without OID's, how do you fix EXACT duplicate records that happen
>> by accident?
> How about tid's? SELECT tid FROM tab1.
"SELECT ctid", actually, but that is still the fallback. (Actually
it always was --- OIDs aren't necessarily unique ei
> > If you want to make oids optional on user tables,
> > we can vote on that.
>
> Let's vote. I'm proposing optional oids for 2-3 years,
> so you know how I'll vote -:)
OK, we need to vote on whether Oid's are optional, and whether we can
have them not created by default.
>
> > However, OID's
> If you want to make oids optional on user tables,
> we can vote on that.
Let's vote. I'm proposing optional oids for 2-3 years,
so you know how I'll vote -:)
> However, OID's keep our system tables together.
How?! If we want to find function with oid X we query
pg_proc, if we want to find tab
> If OIDs are dropped a mechanism for retrieving the primary key of the
> last insert would be greatly appreciated. Heck, it would be useful
> now (rather than returning OID).
>
> I much prefer retrieving the sequence number after the insert than
> before insert where the insert uses it. Especi
> Also, without OID's, how do you fix EXACT duplicate records that happen
> by accident?
How about tid's? SELECT tid FROM tab1.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 8
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
>
> My thought is to make OID generation optional on a per-table basis, and
> disable it on system tables that don't need unique OIDs. (OID would
> read as NULL o
Also, without OID's, how do you fix EXACT duplicate records that happen
by accident?
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/18/01, 3:46:30 PM, Rod Taylo
On Wednesday 18 July 2001 16:06, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
> It remains to be debated exactly how users should control the choice for
> user tables, and which choice ought t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is the idea to make oid's optional, with them disabled by default on
> user tables?
My thought is to make OID generation optional on a per-table basis, and
disable it on system tables that don't need unique OIDs. (OID would
read as NULL on any row for
t;Tom Lane" <[EMAIL PROTECTED]>
To: "Lamar Owen" <[EMAIL PROTECTED]>
Cc: "Bruce Momjian" <[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 4:30 PM
Subject: Re: OID wraparound (was Re: [HACKE
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Wednesday 18 July 2001 16:06, Tom Lane wrote:
>> It remains to be debated exactly how users should control the choice for
>> user tables, and which choice ought to be the default. I don't have a
>> strong opinion about that either way, and am prepared t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yikes, I am not sure we are ready to make oids optional.
>
> We've discussed it enough, it's time to do it. I have an ulterior plan
> here: I want 7.2 not to have any limitations that prevent it from being
> used in a true 24x7, up-forever scenario
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... these two issues of ID wrap need to be addressed -- my gut feel is
> > that the reports of OID/XID wrap are going to skyrocket within 6 months as
> > bigger and bigger installations try out PostgreSQL/RHDB
>
> Yes, my thoughts exactly. We're tr
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't see any value in dropping oid from pg_attribute.
>
> Conservation of OIDs. Assigning an OID to every row of pg_attribute
> chews up lots of OIDs, for a table that should never be referenced by
> OID --- its primary key is (table OID, attrib
On Wednesday 18 July 2001 13:52, Tom Lane wrote:
> here: I want 7.2 not to have any limitations that prevent it from being
> used in a true 24x7, up-forever scenario. VACUUM lockouts are fixed
> now, or nearly. The other stumbling blocks for continuous runs are OID
Go for it, Tom. After the po
Lamar Owen <[EMAIL PROTECTED]> writes:
> ... these two issues of ID wrap need to be addressed -- my gut feel is
> that the reports of OID/XID wrap are going to skyrocket within 6 months as
> bigger and bigger installations try out PostgreSQL/RHDB
Yes, my thoughts exactly. We're trying to play
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Reference name is needed not an object name,
>
> Only if we want to support the notion that
> drop-and-recreate-with-same-name
> means that references from other objects sho
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see any value in dropping oid from pg_attribute.
Conservation of OIDs. Assigning an OID to every row of pg_attribute
chews up lots of OIDs, for a table that should never be referenced by
OID --- its primary key is (table OID, attribute number).
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> BTW, name alone is not a good enough referent for functions... you'd
>> have to store the argument types too.
> ??? Isn't an entry
> pg_proc_relid
> the oid of the function
> pg_type_relid
> the oid of an argument type
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yikes, I am not sure we are ready to make oids optional.
We've discussed it enough, it's time to do it. I have an ulterior plan
here: I want 7.2 not to have any limitations that prevent it from being
used in a true 24x7, up-forever scenario. VACUUM lo
On Wed, 18 Jul 2001, Hiroshi Inoue wrote:
> Oops I made a mistake.
> Reference name is needed not an object name,
> i.e
> object relid
> object oid
> relerence relid
> reference oid
> reference name
>
> create table a (...);
> create view view_a as select .. from
> >
> >Wouldn't that work simply by using the oid for the column in pg_attribute
> >as the primary dependency, rather than the table itself, from pg_class? So,
> >the dependency chain would be:
> >
> >view -> attribute -> table
> >
> >So your examples would 'just work', I think.
> >
>
> True. We
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Reference name is needed not an object name,
Only if we want to support the notion that drop-and-recreate-with-same-name
means that references from other objects should now apply to the new
object. I do not think that that's really a good idea, at leas
Philip Warner <[EMAIL PROTECTED]> writes:
> I think any deisgn needs to cater for attr dependencies. eg.
I don't really see a need to recognize dependencies at finer than table
level. I'd just make the dependency be from view_a to a and keep things
simple. What's so wrong with recompiling the v
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Reference name is needed not an object name,
>
> Only if we want to support the notion that drop-and-recreate-with-same-name
> means that references from other objects should now apply to the new
> object. I do not think that that's really a good i
At 11:38 18/07/01 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> I think any deisgn needs to cater for attr dependencies. eg.
>
>I don't really see a need to recognize dependencies at finer than table
>level. I'd just make the dependency be from view_a to a and keep things
>
> Philip Warner <[EMAIL PROTECTED]> writes:
> > I think any deisgn needs to cater for attr dependencies. eg.
>
> I don't really see a need to recognize dependencies at finer than table
> level. I'd just make the dependency be from view_a to a and keep things
> simple. What's so wrong with recom
Philip Warner <[EMAIL PROTECTED]> writes:
> At 11:38 18/07/01 -0400, Tom Lane wrote:
>> I'd just make the dependency be from view_a to a and keep things
>> simple. What's so wrong with recompiling the view for *every* change
>> of the underlying table?
> Not a problem for views, but when you get
1 - 100 of 140 matches
Mail list logo
