At the same time that we announce support for optional OIDs,
we should announce that, in future releases, OIDs will only be
guaranteed unique (modulo wraparounds) within a single table.
... if an appropriate unique constraint is explicitly created.
Seems reasonable --- that will give
[EMAIL PROTECTED] writes:
... One of the issues I face is
that the WAL files occupy a pretty significant amount of disk space.
Anyone have any pointers?
First off, install the patch depicted at
http://www.ca.postgresql.org/mhonarc/pgsql-patches/2001-06/msg00061.html
CVS tip includes some
Witaj !
Wyjecha³em na wakacje - odpowiem na Twój
list po powrocie.
W sprawach zwi±zanych z firm± SKY-NET
proszê pisaæ bezpo¶rednio na [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and
I would just like to comment that for our project, GNU Enterprise, we
use our own 128 bit object ID that is unique (UUID) for every row in
all tables.
It seems to me, without having looked into it, that having both a
PostgreSQL UID and our own 128 bit objectid (UUID) is redundant and
slows
On Wed, 1 Aug 2001, Bruce Momjian wrote:
This appeared on the JDBC list. Do we need to address this?
Where's Peter Mount? Isn't he the maintainer?
Vince.
I actually consider the biggest problem the fact the the 'official'
postgres jdbc website is very much out of date
I wrote:
Perhaps TRUNCATE should require superuser privilege, just to protect
people from themselves?
Alternative possibilities came to mind just after I hit send ...
1. Refuse TRUNCATE if the table has any DELETE triggers. (Are there
any other conditions to check for?)
2. If the table has
Bruce Momjian [EMAIL PROTECTED] writes:
Found it:
http://fts.postgresql.org/db/mw/msg.html?mid=115140
See the entire thread for the comments about it.
That patch uses SO_PEERCRED, and is the direct ancestor of the
present Debian patches. I haven't seen any code go by that uses
the
Hello All,
I want to know if there's a way to
create a FUNCTION that use a Perl script file?
thanks...
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
I agree it matches the description. That said, it rather surprised me
when Triggers and things didn't go off. Primarily due to the 'Works
like a Delete *'. The description has changed since I first
discovered it though.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel
Makes for a real pain when the nice and safe foreign keys aren't
really nice and safe anymore.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine
Hi,
we're getting back to GiST development and would like to discuss
our plans for 7.2. This discussion doesn't touch any changes in system tables
to solve index_formtuple problem.
We want to discuss implementation of null-safe interface to GiST
(for reference see thread
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
This patch is because Hurd does not support NOFILE. It is against current
cvs.
The Debian bug report says, The
Is TRUNCATE supposed to be equivalent to DELETE FROM blah?
Because I notice that DELETE triggers are not called when you truncate a
table... Isn't that a bad thing?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
[EMAIL PROTECTED] (Nathan Myers) writes:
At the same time that we announce support for optional OIDs,
we should announce that, in future releases, OIDs will only be
guaranteed unique (modulo wraparounds) within a single table.
Seems reasonable --- that will give people notice that
There is some code in gram.y that detects whether you are in a RULE so
NEW/OLD can be detected. Seems the value is reset on parser start and
set on RULE start, but not reset on rule and. A multi-query string
could use NEW/OLD in the queries after the RULE even though they are
invalid. The
Oliver Elphick [EMAIL PROTECTED] writes:
If there is a comment on a view, pg_dumpall can put them in the wrong order:
I've committed a fix for this in both CVS tip and REL7_1_STABLE.
regards, tom lane
---(end of
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Why rename VACUUM, why not create a new command RECLAIM, or something like
that. RECLAIM does the VACUUM NOLOCK, while vacuum does the locking.
Um, that gets the default backwards IMHO, where default = what
existing scripts will do.
Oleg Bartunov [EMAIL PROTECTED] writes:
2. For union and picksplit we propose to clean up NULLs from array of
keys, so support of arguments 'passed-by-value' will not require
changes of user interface. It would require some modification of current
algorithm of splitting, but
I'm not sure this is related to the OID discussion, however I have seen
designs where a unique id is required for all the objects in the
database.
This (IMO) this implies an int8 (or larger) sequence number.
It would be nice if we could have different size sequences. Just thought
I'd throw
Hannu Krosing wrote:
mlw wrote:
I posted this question earlier, but it looks like it never made it on.
If you can control the OIDs on a per table basis, and some tables need not even
have any, why not let each table have its own OID range? Essentially, each
record will be numbered
Hannu Krosing [EMAIL PROTECTED] writes:
That would probably be a problem with 4-byte OIDs, there is an ample
supply of 8-byte ones
Sure, but I think we are still a few years away from being able to
assume that every platform of interest can support 8-byte OIDs (and
furthermore, won't see a
21 matches
Mail list logo
