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
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 th
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, bu
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 wil
"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 broadcast)---
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 follo
> [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 t
Tom Lane wrote:
>
> > VACUUM DEFRAG?
> > VACUUM COMPRESS?
>
> While these look kinda ugly to me, I can find no stronger objection than
> that. (Well, maybe I could complain that these overstate what old-style
> vacuum actually does, but that's even weaker.) What do other people
> think?
Wha
Tom Lane wrote:
>
[Snipped]
I think making "WITHOUT OIDS" the default for table creation is the right thing
to do. Here is my reasoning:
An OID is a system wide limitation. 4B or 2B depending on sign-ness. (could
there be some bugs still lurking on high OIDs?) Since the OID is a shared
system w
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 up
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 t
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 http://fts.postgresql.org
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 w
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
> > (http
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
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 un
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
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 relative to 0 on its ta
[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
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Hmm there seems to be an assumption that people could
> > know whether they need OID or not for each table.
>
> A good point, and one reason not to make no-OIDs the default. I'm
> envisioning that people will turn off OIDs only fo
Christopher Kings-Lynne wrote:
>
> 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?
It's supposed to work that way - same as Oracle.
Mike Mascari
[EMAIL PROTECTED]
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 h
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Based on the discussion so far, here is an attempt to flesh out the
>> details of what to do with OIDs for 7.2:
> Also OIDS should be promoted to 8-byte integers at some future time.
Perhaps, but I'm trying to focus on what to do for
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking about our new version of vacuum. I think it should be
> > called VACUUM NOLOCK to make it clear when you should use it, and we can
> > keep our ordinary VACUUM the same.
>
> I really don't understand why you're so hot to avoid changi
On Thu, Aug 02, 2001 at 09:28:18AM +0200, Zeugswetter Andreas SB wrote:
>
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption.
>
> I for one am more concerned about adding additional
> > 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 wi
26 matches
Mail list logo
