We are seeing what seems to me to be very peculiar behaviour. We have a
schema upgrade script that alters the schema of an existing production
database. One of the things we do is create two new indexes. The script
then immediately performs a vacuum analyze.
The problem is (or was) that this ana
> I just had an idea about how to avoid this cost:
> why not recycle old log segments? At the point where the code
> currently deletes a no-longer-needed segment, just rename it to
> become the next created-in-advance segment.
Yes, since I already suggested this on Feb 26. I naturally think thi
Hi,
I use the libraries of function of Postgres in a
program.
In this script, I keep connected with the postmaster
and I submit him a lot of queries without
disconnecting each time. At the end of each queries, I
use PQclear to clean memory but I notice that the
memory used by the process postgres
Hello,
I have a problem white one sql request. I got this error message :
Warning: PostgreSQL query failed: ERROR: SELECT DISTINCT ON expressions
must match initial ORDER BY expressions in
/export/castor-b7/local-home/kelbertj/Prog/web/lumiere/admin/recherche_realisateurs.php
on line 85 ERROR: S
Bruce Momjian wrote:
> As some of you know, Nusphere is trying to sell MySQL with an additional
> transaction-based table manager called Gemini. They enabled download of
> the source code yesterday at:
>
>http://mysql.org/download3.php?file_id=1118
>
> Looking through the 122k lines of C code
How do I define a function as taking a variable number of parameters. The
documentation seems to indicate (...) but, no such luck.
markw=# create function concat( ... )
markw-# returns varchar
markw-# as '/usr/local/lib/pgcontains.so', 'concat'
markw-# language 'c' with (
Hmmm... my prior appends to this newsgroup are stalled. Hopefully,
they'll be available soon.
Tom Lane wrote:
>
> What you may really be saying is that the existing scheme for management
> of log segments is inappropriate for PIT usage; if so feel free to
> propose a better one. But I don't se
On Tue, Jul 17, 2001 at 07:13:10PM -0400, Tom Lane wrote:
>
> Nonetheless, a properly indexed pg_depend table would allow you to find
> these objects directly, and again to find their dependents directly,
> etc. The brute force approach would require a rather expensive scan
> over all the system
>
>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 need to remember to st
On Wed, Jul 18, 2001 at 01:08:15PM +1000, Philip Warner wrote:
> At 11:25 18/07/01 +0900, 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
> > referenc
First, are you using the latest PG? I was under the impression that all
the hard-coded limitations on size had been eliminated in the latest
releases. I know for an absolute fact that I can insert multi-megabyte sized
text chunks in PG 7.1.2 as I've done just that before...
Good luck!
-M
Patrick Macdonald <[EMAIL PROTECTED]> writes:
> Yes, but in a very roundabout way (or so it seems). The main point
> that I was trying to illustrate was that if a database supports
> point-in-time recovery, recycling of the only available log segments
> is a bad thing.
Certainly, but deleting
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Yes, since I already suggested this on Feb 26.
So you did. Darn, I thought it was original ;-)
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our ex
Tim Allen <[EMAIL PROTECTED]> writes:
> The problem is (or was) that this analyze didn't seem to work. Queries
> performed thereafter would run slowly. Doing another vacuum analyze later
> on would fix this, and queries would then perform well.
This makes no sense to me, either. Can you put toge
On Wed, 18 Jul 2001, Kelbert wrote:
> Hello,
>
> I have a problem white one sql request. I got this error message :
>
> Warning: PostgreSQL query failed: ERROR: SELECT DISTINCT ON expressions
> must match initial ORDER BY expressions in
>
>/export/castor-b7/local-home/kelbertj/Prog/web/lumiere
Hi!
> "Nathan" == Nathan Myers <[EMAIL PROTECTED]> writes:
Nathan> On Wed, Jul 18, 2001 at 08:35:58AM -0400, Jan Wieck wrote:
>> And this press release
>>
>> http://www.nusphere.com/releases/071601.htm
>>
>> also explains why they had to do it this way.
Nathan> They were always free to
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 m
Hi!
> "Jan" == Jan Wieck <[EMAIL PROTECTED]> writes:
Jan> Moin Monty,
Jan> dear fence-guests,
Thanks.
>> Please note that we NEVER have asked NuSphere to sign over copyright
>> of Gemini to us. We do it only for the core server, and this is
>> actually not an uncommon thing among open so
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?
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
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
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
> 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
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
> Nonetheless, at some point an old WAL segment will become deletable
> (unless you have infinite space on your WAL disk). ISTM that at that
> point, it makes sense to consider recycling the file rather than
> deleting it.
Of course, if you plan to keep your WAL files on the same drive, you
don'
On Wed, Jul 18, 2001 at 11:45:54AM -0400, Bruce Momjian wrote:
> > And this press release
> >
> > http://www.nusphere.com/releases/071601.htm
> ...
> On a more significant note, I hear the word "fork" clearly suggested
> in that text. It is almost like MySQL AB GPL'ed the MySQL code
> Hmmm... my prior appends to this newsgroup are stalled. Hopefully,
> they'll be available soon.
>
> Tom Lane wrote:
> >
> > What you may really be saying is that the existing scheme for management
> > of log segments is inappropriate for PIT usage; if so feel free to
> > propose a better one.
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
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
>
And the story goes on...
http://www.newsforge.com/comments.pl?sid=01/07/18/0226219&commentsort=0&mode=flat&threshold=0&pid=0
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's b
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
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 Taylor <[EMAIL PROTECTED]> wrote regarding Re:
OID wraparound (was Re: [HACKERS] pg_depend) :
> If OIDs are dropped a
> * Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> | Most Unix filesystems will not allocate disk blocks until you write in
> | them. If you just seek out past end-of-file, the file pointer is moved
> | but the blocks are unallocated. This is how 'ls' can show a 1gb file
> | that only uses 4k of
>> 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
Hi!
As I do have some insight in these matters, I thought I would comment
on this thing
> "Jan" == Jan Wieck <[EMAIL PROTECTED]> writes:
Jan> Bruce Momjian wrote:
>> As some of you know, Nusphere is trying to sell MySQL with an additional
>> transaction-based table manager called Gemini.
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
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
"Steve Howe" <[EMAIL PROTECTED]> writes:
> Writing my interface application, which use the PQexec library, I
> came across the PQexec() queries 8191 bytes limit.
You must have a very out-of-date library. Time to update.
regards, tom lane
> 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
currval() could work nicely, but thats an additional query. Currently
OID (in php among others) can be retrieved along with the insert
response which is instantly retrievable. This makes for a very quick
middleware enforced foreign key entry in other databases.
Returning the entire primary key
Hi Steve, lets approach this from the other angle...
I don't see anywhere in your email where you say what makes you think that
you can only pass a query > 8191 bytes in size to PG. What exactly makes you
think that there is some hard coded limit? This limit is not in 7.1.2 so
either you have out
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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I'm playing around with the Full Text Indexing module, and I notice that
> it's case-sensitive. This seems to be pretty useless to me - especially for
> my application. I wonder if there'd be any objections to me modifying it to
> be case-i
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 08:35:58AM -0400, Jan Wieck wrote:
> And this press release
>
> http://www.nusphere.com/releases/071601.htm
>
> also explains why they had to do it this way.
They were always free to fork, but doing it the way they did --
violating MySQL AB's license --
> 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
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
--
> -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
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
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
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
For the record:
http://www.lineone.net/dictionaryof/englishusage/d0081889.html
dependent or dependant
"Dependent is the adjective, used for a person or thing that depends
on someone or something: Admission to college is dependent on A-level
results. Dependant is the noun, and is a pers
> 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
> And this press release
>
> http://www.nusphere.com/releases/071601.htm
>
> also explains why they had to do it this way. They disagreed
> with the policy that every code added to the core system must
> be owned by MySQL AB, so that these guys can sell it for
>
> 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
> 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 wrote:
>
> > Hmmm... my prior appends to this newsgroup are stalled. Hopefully,
> > they'll be available soon.
> >
> > Tom Lane wrote:
> > >
> > > What you may really be saying is that the existing scheme for management
> > > of log segments is inappropriate for PIT usage; if so fe
> >> 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
> 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:
> 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
Err PG_DUMP nightly on a 38,000,000+row table that takes forever to
dump/unload, and gets updated every 5 minutes with 256KChar worth of
updates?
Give me a FAST pg_dump, and I'll think about it, until then, no
LER
(PS: this is also a reason for making a pg_upgrade work IN PLACE on a
> > > Yes, but in a very roundabout way (or so it seems). The main point
> > > that I was trying to illustrate was that if a database supports
> > > point-in-time recovery, recycling of the only available log segments
> > > is a bad thing. And, yes, in practice if you have point-in-time
> > > re
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. Especially when tr
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
> > 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
Michael Widenius wrote:
>
> Hi!
Moin Monty,
dear fence-guests,
> Please note that we NEVER have asked NuSphere to sign over copyright
> of Gemini to us. We do it only for the core server, and this is
> actually not an uncommon thing among open source companies. For
> example QT (Trolltech) and X
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
Hello all,
Writing my interface application, which use the PQexec library, I
came across the PQexec() queries 8191 bytes limit.
What useful are 4Gb text fields if I have this limit ?
I mean, if a user make an update to this field, with a large value
(let's say, 4Mb), do I
On Wed, Jul 18, 2001 at 06:37:48PM -0400, Trond Eivind Glomsr?d wrote:
> Michael Widenius <[EMAIL PROTECTED]> writes:
> > Assigning over the code is also something that FSF requires for all
> > code contributions. If you criticize us at MySQL AB, you should
> > also criticize the above.
>
> This
> >
> >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
> > > : Most Unix filesystems will not allocate disk blocks until you write in
> > > : them. [...]
> > >
> > > Yes, I understand that, but how is it a problem for postgresql?
> >
> > Uh, I thought we did that so we were not allocating file system blocks
> > during WAL writes. Performance is bad
Hello,
I have a problem white one sql request. I got this error message :
Warning: PostgreSQL query failed: ERROR: SELECT DISTINCT ON expressions
must match initial ORDER BY expressions in
/export/castor-b7/local-home/kelbertj/Prog/web/lumiere/admin/recherche_realisateurs.php
on line 85 ERROR: S
* Bruce Momjian <[EMAIL PROTECTED]> wrote:
| Most Unix filesystems will not allocate disk blocks until you write in
| them. If you just seek out past end-of-file, the file pointer is moved
| but the blocks are unallocated. This is how 'ls' can show a 1gb file
| that only uses 4k of disk space.
> 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
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
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
> This is slightly different - FSF wants it so it will have a legal
> position to defend its programs:
There is at least one documented case where the FSF has used
that right to sell a non-open license for GCC to Motorola.
- Sascha Experience IRCG
"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 <[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
[
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?
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
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.
>
> We've discussed it enough, i
> 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
> > > Of course not. As mentioned, you'd probably archive them with your
> > > backup(s).
> >
> > You mean the nigthly backup? Why not do a pg_dump and be done with it.
>
> But the purpose of point-in-time recovery is to restore your backup
> and then use the WAL to bring the backed up image
FYI, I will be visiting Red Hat engineers in Toronto tomorrow
(Thursday). I will be back online Friday.
I should also mention that Jan, Tom, and I will be at the O'Reilly
conference all next week.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
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
>> 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.
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
At 06:10 PM 18-07-2001 -0400, Lamar Owen wrote:
>applications :-) I guess I'll just need to switch to proper SERIALs and
>PRIMARY KEYs. Of course, if I wanted to be stubborn, I'd just use the GUC
>option to enable OIDs system-wide by default
The default 32 bit serial primary key isn't
Didn't know about that one, at least from the reading of the docs...
Thanks,
You answered the question. I knew OID's weren't unique, but they are
likely to be able to distinguish between 2 rows in the same table.
Maybe ctid needs to be documented better?
LER
>> Original Me
Hi...
The problem is, I compiled it myself from original PostgreSQL
version 7.12 C sources using Microsoft's Visual C++ 6.0. I had to compile it
because I add a function to free the handlers returned from PQnotifies(), or
I would have a memory leak.
The resulting libpq.dll seems o
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
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
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
"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:
> 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).
Michael Widenius <[EMAIL PROTECTED]> writes:
> Please note that we NEVER have asked NuSphere to sign over copyright
> of Gemini to us. We do it only for the core server, and this is
> actually not an uncommon thing among open source companies. For
> example QT (Trolltech) and Ximian (a lot of gno
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
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
1 - 100 of 107 matches
Mail list logo
