Im sorry but I didn't understand what you mean with the UPDATE.
Anyway, it don't apply to my point. I must do an insert in each row of my
ingresso table with his Id, some fields and the id of my cartao table.
You help is very welcomed but my solution doesn't came this time.
My best regards
Ezeq
Apologies the first statement should have included the column name to
insert to:
INSERT INTO base.ingresso (id_column) (SELECT id FROM base.cartao ORDER BY
id)
That will insert one row in ingresso for each row in cartao only changing
the id column. All the other columns in each row will be
The second statement works but only 1 row was affected. It do not apply to
me.
The first statement i didn't understand. You are adding only the first field
on my base.ingresso table ?
Regards
Ezequias
2007/2/25, Phillip Smith <[EMAIL PROTECTED]>:
(Please reply to the list when replying)
T
(Please reply to the list when replying)
The error is correct - you are telling PG to insert one row (the literal
values you've passed to INSERT), but the sub-query is returning multiple
rows which won't fit in a single row.
I see 2 options, but someone else I'm sure will have a more elegan
On Sun, Feb 25, 2007 at 01:34:44PM -0500, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > If 8.2, what about
> >... WHERE foo IN (select x from (values (1$),(2$),...,(N$)) as t(x))
> > ?
>
> Well, the OP wasn't using 8.2 --- judging from the selected plan, it had
> to be 8.0 or ol
Joe Conway <[EMAIL PROTECTED]> writes:
> If 8.2, what about
>... WHERE foo IN (select x from (values (1$),(2$),...,(N$)) as t(x))
> ?
Well, the OP wasn't using 8.2 --- judging from the selected plan, it had
to be 8.0 or older. But yeah, a values-list is an interesting
alternative on 8.2. I t
Tom Lane wrote:
Richard Jones <[EMAIL PROTECTED]> writes:
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
PG 8.2 does better with long IN-lists ... although if the list is so
long as to be fetching a significant f
Richard Jones <[EMAIL PROTECTED]> writes:
> I've been profiling a PG database / mix of applications and found that
> one statement which takes a very long time to execute is:
PG 8.2 does better with long IN-lists ... although if the list is so
long as to be fetching a significant fraction of the t
Richard,
contrib/intarray may help you.
On Sun, 25 Feb 2007, Richard Jones wrote:
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
select e.keywordid, e.quantity, e.max_cpc, i.position
from bid3_events_imp
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
select e.keywordid, e.quantity, e.max_cpc, i.position
from bid3_events_impressions i, bid3_events e
where i.eventid = e.id and e.keywordid in ($1,$2,$3,
10 matches
Mail list logo
