sit IS NULL
BTW, this works too:
select null+1; -- obviously returns NULL
System is FreeBSD 4.1, PgSQL 7.0.2
Anyone got a clue?
Yours sincerely,
Edmar Wiggers
BRASMAP Information Systems
+55 48 9960 2752
wever, that's the only whay to do it (use something similar to
stored procs). And, true, that's much better than not doing it at all.
Yours sincerely,
Edmar Wiggers
BRASMAP Information Systems
+55 48 9960 2752
tablename;
(which is used to reset a sequence)
That should be done with
EXECUTE procedure(tablename_name,sequence_name);
(not sure if execute is the right keyword)
Yours sincerely,
Edmar Wiggers
BRASMAP Information Systems
+55 48 9960 2752
Is there any PostgreSQL developer working on the OpenACS (PG version of the
ArsDigita Community Sytem) project?
I have installed it and I am very much interested. There are a lot of small
bugs though, mostly related to Oracle->Postgres migration, and some which
are Postgres specific (queries that
IMHO you should use another table instead of an array.
Forget about reasonable speed when using IN sub-queries, you'll get a
sequential scan of the sub-query for every row in the master select. I've
heard the EXISTS operator provides far better performance.
In 7.1, there's a very nice solution:
I believe the known mechanism to cope with errors inside transactions are
savepoints. That doesn't seem to be the case, though.
If you don't care if some inserts fail, then you have multiple transactions
instead of just one (use autocommit).
If you want a transaction, check existence before eac
nted using a sequence object (see the docs). Once
a sequence returns a number it will never return it again (that's what
sequences are for!).
A serial field is not a good approach if you always want to start numbering
at 1.
Yours sincerely,
Edmar Wiggers
BRASMAP Information Systems
+55 48 9960 2752
> > Check existence and then insert or update. If you want, I guess
> you could
> > wrap that inside a stored procedure.
> >
> Well, that's a good idea :-) but I'm not sure about how to create
> such procedure. I would appreciate Your help.
Quite frankly, I'm not sure either. I'm just
> If I try to insert some row which in the table already exist the
> postgre don't insert it and tell some error. Everything ok.
> I'll insert only if there is not the same (same key) record,
> else don't insert and don't tell me errors about it.
> In MySQL is a switc
> The results were that PgSQL was slower than MySQL only by a
> factor of 2 or 3
> (say, 3 seconds for MySQL against 6 or 8 seconds for PgSQL).
> Pretty good in
> my opinion.
I forgot to stress that the test was run using *MySQL* benchmark tools,
connecting against MySQL and PostgreSQL. I had to
As a former Oracle developer, I decided to start working with cheaper
DBMS's. After a quick look on the market, PostgreSQL was the only one really
worth looking into.
But people liked MySQL, and I had to look for benchmarks. I found only one
(attached).
Not satisfied, I got PostgreSQL and MySQL
How does PostgreSQL handles a "too big" transaction?
By that I mean a transaction which, after a certain point, there will be no
way to roll back. On PgSQL, maybe that only happens when the disk fills. Is
there a configurable "size" limit for a single transaction?
In addition, what happens if th
12 matches
Mail list logo
