On 8/14/07, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
> Thank you for this detailed explanation Alban. But I want to include
> FK constraints on a table2 on a column in the referenced table1 where
> column values are not unique.
>
> I just want row data to be consistent for the same ID. Yes, this i
On 8/14/07, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
> > *And* you can define compound foreign key constraints,
> Thank you for this detailed explanation Alban. But I want to include
> FK constraints on a table2 on a column in the referenced table1 where
> column values are not unique.
>
> I just
"Phoenix Kiula" <[EMAIL PROTECTED]> writes:
> There are some cases where I would like to bunch queries into a
> transaction purely for speed purposes, but they're not interdependent
> for integrity. E.g.,
How do you know you need to do this for speed if you haven't run it yet? I
would suggest you
> You could do this with savepoints which are a kind of sub-transaction inside a
> "bigger" transaction.
>
> e.g.:
> BEGIN TRANSACTION;
>
> SAVEPOINT sp1;
> UPDATE1;
> IF (failed) rollback to savepoint sp1;
>
> SAVEPOINT sp1;
> UPDATE2;
> IF (failed) rollback to savepoint sp2;
Thanks Thomas, thi
On 8/14/07, Bill Moran <[EMAIL PROTECTED]> wrote:
>
> But the rule is, if any query within the transaction errors, then all
> queries
> within the transaction are rolled back.
This is the default behaviour, but with psql and ON_ERROR_ROLLBACK parameter
the behaviour can be changed. See
http://w
Phoenix Kiula wrote on 14.08.2007 19:46:
There are some cases where I would like to bunch queries into a
transaction purely for speed purposes, but they're not interdependent
for integrity. E.g.,
BEGIN TRANSACTION;
UPDATE1;
UPDATE2;
UPDATE3;
COMMIT;
If UPDATE2 fails because it, say, v
In response to "Phoenix Kiula" <[EMAIL PROTECTED]>:
> > If you issue a BEGIN then nothing gets committed until you issue a COMMIT.
> > If
> > anything happens in the meantime then everything you've done since the BEGIN
> > disappears.
>
> There are some cases where I would like to bunch queries
> If you issue a BEGIN then nothing gets committed until you issue a COMMIT. If
> anything happens in the meantime then everything you've done since the BEGIN
> disappears.
>
There are some cases where I would like to bunch queries into a
transaction purely for speed purposes, but they're not in
> You're confusing CHECK constraints and FOREIGN KEY constraints. They're
> different things ;)
>
> CHECK constraints verify that data in a certain column matches a certain
> condition. I'm not sure they can reference columns in other tables,
> unless you wrap those checks in stored procedures mayb
On 8/14/07, Alban Hertroys <[EMAIL PROTECTED]> wrote:
> *And* you can define compound foreign key constraints,
> for example:
>
> CREATE TABLE employee (
> employee_id serial NOT NULL,
> company_id integer NOT NULL,
> name text NOT NULL,
> CONSTRAINT employee_pk
>
Phoenix Kiula wrote:
> Agree. That's what I am trying to do. Include as many UPDATEs etc into
> the same TRANSACTION block, but my worry is when I read about
> autocommit and how it is enabled by default in postgresql 8.
> Specifying explicit BEGIN and COMMIT blocks should only commit when I
> want
"Phoenix Kiula" <[EMAIL PROTECTED]> writes:
> If I am reading this right, does this mean it is probably better to
> leave fsync as "fsync=off" on production machines?
Only if you can reconstruct your data from other sources in the case of a
server crash or power failure. I wouldn't recommend it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/07 10:09, Phoenix Kiula wrote:
> On 14/08/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> "Phoenix Kiula" <[EMAIL PROTECTED]> writes:
[snip]
>>>
>>> QUESTION1:
>>> Is this it? Or am I missing something in terms of execution? We use
>>> Perl o
Thank you AM. Very useful note, must appreciate the info you shared.
About COPY, I have two simple questions:
1. Is there anything like an ALTER DATABASE command? I would like to
change the character set without having to recreate the DATABASE
again!
2. Also, when I do a mysqldump I seem to be e
On Tue, Aug 14, 2007 at 11:09:36PM +0800, Phoenix Kiula wrote:
> If I am reading this right, does this mean it is probably better to
> leave fsync as "fsync=off" on production machines?
No, you want "fsync=on" on any machine which holds data you
care about. And you want hardware which doesn't lie
On 14/08/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Phoenix Kiula" <[EMAIL PROTECTED]> writes:
>
> > Though other threads I have learned that multiple inserts or updates
> > can be sped up with:
> >
> > [QUOTE]
> > - BEGIN TRANSACTION;
> > - INSERT OR UPDATE queries, ideally PREPAREd;
> > - CO
"Phoenix Kiula" <[EMAIL PROTECTED]> writes:
> Though other threads I have learned that multiple inserts or updates
> can be sped up with:
>
> [QUOTE]
> - BEGIN TRANSACTION;
> - INSERT OR UPDATE queries, ideally PREPAREd;
> - COMMIT;
> [/QUOTE]
>
> QUESTION1:
> Is this it? Or am I missing something
I have been a long time user of mysql. Switching to Postgresql because
the true features included in 5.1 (as of this moment) are nothing to
write home about. The InnoDB stuff is highly advocated but it has its
own set of issues, and when one looks at things like backup/restore
etc, it is clearly ta
18 matches
Mail list logo
