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
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
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 sleepy
Bruce Momjian wrote:
>
> Can I ask where we are on this?
Sure - posted a follow up to the list a while ago. Subject was
"RAISE : state of play and request for advice"
Currently, this works:
CREATE FUNCTION foo_raise_loop(text) RETURNS text AS '
DECLARE
a ALIAS FOR $1;
i integer;
Thanks that will help a lot. I searched through July and August
archives, but should have gone back to June too :(
I'd like to keep the total space consumed by the WAL files to under
3 MB or so. Not sure if thats practical or not. I'll experiment with
the provided patch. We did figure out how t
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.
> Tom,
>
> please apply attached patch to current CVS.
>
> 1. Fixed error with empty array ( '{}' ),
>test data change
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Just a quick question - when does stuff need to be in for 7.2?
There's not an agreed schedule yet. Personally I'd like to see us
release a beta before I go off to LinuxWorld (8/28) ... it'd be nice
to be able to say "7.2 is in beta" at the
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 per
> tuple overhead (moving from 32 -> 64b
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 changing the
defau
If there is a comment on a view, pg_dumpall can put them in the wrong order:
--
-- pg_dumpall (7.2devel)
--
...
--
-- TOC Entry ID 363 (OID 31291)
--
-- Name: VIEW "all_persons" Type: COMMENT Owner:
--
COMMENT ON VIEW "all_persons" IS 'All persons - individuals or not';
--
-- TOC Entry ID 362 (
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The followings are the result of vote which I remember
> well.
FWIW, I changed my vote ;-). I'm not sure what Vadim and Lamar think
at the moment, but I thought you made good arguments.
regards, tom lane
--
> On Thu, 2 Aug 2001, Bruce Momjian wrote:
>
> > Yes! That was it the Solaris patch I remember, SCM_CREDENTIALS.
>
> Can you provide a pointer to this patch? I just grepped Solaris includes
> in vain for SCM_CRED.
>
> The keyword "SCM_CREDENTIALS" is actually used by Linux, whereas FreeBSD
> u
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I really don't understand why you're so hot to avoid changing the
>> default behavior of VACUUM.
> I am concerned because UPDATE consumes disk space that never gets
> returned to the OS until a traditional vacuum is run.
Not necessarily. Concurrent V
Nathan Myers wrote:
>
> 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
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
> If there is a comment on a view, pg_dumpall can put them in the wrong order:
Drat. I fixed the identical problem for permissions a little while ago,
but didn't realize that it extended to comments too. Thanks for the
report!
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 for tables that they
know will b
Read the docs:
http://www.postgresql.org/users-lounge/docs/7.1/postgres/plperl.html
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of gabriel
> Sent: Friday, 3 August 2001 2:29 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] FUNCTION Question...
>
>
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".
> The term RECLAIM will
Tom Lane wrote:
>
> > Maybe just call the traditional vacuum VACUUM LOCK. It was the
> > LOCK/NOLOCK idea that I think was important.
>
> Right now it's called VACUUM FULL, but I'm not particularly wedded to
> that name. Does anyone else like VACUUM LOCK? Or have an even better
> idea?
Why r
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not here on BSD/OS. I know I saw a Solaris patch that did exactly this
> and I questioned it because it was only for Solaris. Now that I
> research and I see different OS's doing this different ways, and I have
> mucked up hba.c already, it seemed like
Helge Bahmann <[EMAIL PROTECTED]> writes:
> Most certainly they do not, or at least it is called differently; I
> grepped includes of: FreeBSD 4.2, Solaris 8, Irix 6.5 and AIX (4.3?) and
> did not find SO_PEERCRED.
> On FreeBSD (and I guess Solaris as well) it is possible to pass
> credentials us
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can someone find the Solaris patch submitted a few months ago that did a
> > similar thing? I can't seem to find it.
>
> I couldn't find one either. I found a couple of unsupported assertions
> that Solaris and *BSD had SO_PEERCRED, so the Linux p
> Ah, now I understand: those references I saw mention the existence of
> the underlying SCM_CREDENTIALS (or whatever it's called) message type,
> not the SO_PEERCRED getsockopt facility.
Yes! That was it the Solaris patch I remember, SCM_CREDENTIALS.
> I agree that it's not worth pursuing at t
> 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 per
tuple overhead (moving from 32 -> 64bit) than loosing OID's
on some large tables
24 matches
Mail list logo
