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 could say,
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?). How
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.
Hmm ... within a
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 and make objects
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 of OID?
I
I've followed the threads of needing to run vacuum nightly, and even
got an answer to a slow updating database regarding needing to vacuum. But I
haven't see the question asked:
is it possible to completely turn off the revision tracking feature so that
vacuum does not need to be run at
Michael == Michael Widenius [EMAIL PROTECTED] writes:
Michael Please note that we NEVER have asked NuSphere to sign
Michael over copyright of Gemini to us. We do it only for the
Michael core server, and this is actually not an uncommon thing
Michael among open source companies.
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 pg_class where
Mark Volpe [EMAIL PROTECTED] writes:
ERROR: Only users with Postgres superuser privilege are permitted to create a
function in the 'plpgsql' language.
D'oh! So, if this is the case, then the last patch should be fine after all.
No, evidently you broke something, or your plpgsql is installed
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
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?
Not a
I need to programatically relax a constraint during db syncronization. I
tried setting tgenabled to false in the pg_trigger table, but it didn't seem
to make a difference.
Thx,
Howie
---(end of broadcast)---
TIP 5: Have you checked our
You are right; I have forgotten to create a trusted language.
Mark
Tom Lane wrote:
Mark Volpe [EMAIL PROTECTED] writes:
ERROR: Only users with Postgres superuser privilege are permitted to create a
function in the 'plpgsql' language.
D'oh! So, if this is the case, then the last
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 excited
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, would be
Mike Cianflone [EMAIL PROTECTED] writes:
is it possible to completely turn off the revision tracking feature so that
vacuum does not need to be run at all?
No.
Of course, if you never update or delete any rows, you don't need VACUUM
... but I suspect that's not what you had in mind.
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,...}
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 they'd
19 matches
Mail list logo
