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?
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
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
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
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
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
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
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]
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
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
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
> 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
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
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
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
> >> 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
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
> 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
[ way off topic, but I can't resist ]
[EMAIL PROTECTED] (Nathan Myers) writes:
> 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: Admi
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
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
> 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
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
> 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
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 --
> 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
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.
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
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
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
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 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
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
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
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
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
>
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
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
> > > 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
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
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
> >
> >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
"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
> 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
>
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
"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:
> 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
> > > 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
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
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
> * 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
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
>
> 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'
Bruce Momjian wrote:
>
> > > > 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
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
> 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
> 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.
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
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
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
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
>
>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 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
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
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 (
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
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
1 - 100 of 107 matches
Mail list logo
