Thanks, Jim. I'll give it a try.
On Tue, 2006-10-10 at 21:11 -0500, Jim C. Nasby wrote:
> On Tue, Oct 10, 2006 at 03:21:36PM -0400, [EMAIL PROTECTED] wrote:
> > Everyone,
> >
> > I've written a function (language = sql) which uses a temporary table to
> > simplify the process; however, when I g
Hi, Dirk,
Dirk Jagdmann wrote:
> So for a batch of inserts the value of a stays the same, while for by
> arbitrary values are inserted. Now I have wondered if PostreSQL offers
> a smarter way to insert those values? A solution can contains usage of
> some plpgsql code.
[local]:postgres=# insert
Hi, Daniel,
Daniel Drotos wrote:
> What is the best way to do something like:
>
> delete from tablename where something order by somefield...
There should be no need for this, because a delete is atomic due to the
transaction system.
What is it that you're trying to achieve with the ordered d
On Wed, 11 Oct 2006, Markus Schaber wrote:
What is it that you're trying to achieve with the ordered delete? Maybe
there's a better way to solve your underlying problem.
I've a table which has a field for some info (number) and a date field
(insertion date) and others.
After inserting new r
I am having a problem with the performance of a
view that will be a critical part of a database system
I am working on, and would appreciate some advice.
Apologies for the length of this posting!
I have a parent table P and to child tables A and B,:
CREATE TABLE p (
id INT NOT NULL PRIMARY
On 2006/10/11 Stuart wrote:
> [..]
Apologies for following up my own post, but after
struggling with that query for over a day, I figured
out the answer within thirty minutes of posting.
(Sigh)
My slow query was:
> SELECT p.id AS pid, a.id AS aid, sub.bid AS bid
> FROM p
> JOIN a ON
I got bit by this to be sure, but is it a bug? I guess I'd hoped for a
warning at the critical step (see "poof" below):
create table tester (one int, two int, three int);
alter table only tester add constraint no_dupes unique (one, two, three);
insert into tester values(1,2,3);
insert into tester
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> I got bit by this to be sure, but is it a bug? I guess I'd hoped for a
> warning at the critical step (see "poof" below):
> create table tester (one int, two int, three int);
> alter table only tester add constraint no_dupes unique (one, two, three);
>
