On 11.07.2007 08:10, Dat Chu wrote:
I am the new sysadmin and was given the task to move a postgresql
installation from one box to another. So I want to do pg_dumpall .
However, there is no record of postgresql superuser/root password. I
do have root access to the system however.
Does anyone
On Jul 10, 2007, at 3:09 PM, Tom Lane wrote:
Harpreet Dhaliwal [EMAIL PROTECTED] writes:
Transaction 1 started, saw max(dig_id) = 30 and inserted new
dig_id=31.
Now the time when Transaction 2 started and read max(dig_id) it
was still 30
and by the time it tried to insert 31, 31 was
Am Freitag, 6. Juli 2007 11:15 schrieb Stefan Christ:
the documentation of PGSQL 8.0 tells me, that extract(dow ...) will
return 0 for Sundays. I know that this behaviour depends on the
language settings on MSSQL, so that I have to correct this settings
with an offset. What is the behaviour in
Hello,
I use MS Access for data import. Access imports csv file, make some
calculation and transffers data to PostgreSQL.
Unfortunately, it takes a lot of time to transfer data to PostgreSQL.
My odbc settings are following:
[ODBC]
DRIVER=PostgreSQL Unicode
UID=postgres
XaOpt=1
am Wed, dem 11.07.2007, um 14:15:02 +0200 mailte Zlatko Matic folgendes:
Hello,
please don't hijack other threads. If you only change the subject for a
new question, your mail will be sorted completely wrong.
(within modern email-clients such thunderbird or mutt)
I use MS Access for data
Hi. I'm having some strange round behaviour when using 4 decimals.
If I use ROUND(1.8947, 2), it should return 1.90, but it does return 1.89.
Rounding to 3 decimal places, then 2 (eg.: ROUND(ROUND(1.8947, 3), 2) ) then
I get 1.90!
This way, when rounding, ROUND is considering only decimal places
I have already tried COPY.
But, it has problems with type castings.
For example, COPY operation fails because PostgreSQL can't copy value
7.844,000 into NUMERIC field...
Regards,
Zlatko
- Original Message -
From: A. Kretschmer [EMAIL PROTECTED]
To: pgsql-general@postgresql.org
am Wed, dem 11.07.2007, um 14:55:28 +0200 mailte Zlatko Matic folgendes:
I have already tried COPY.
But, it has problems with type castings.
For example, COPY operation fails because PostgreSQL can't copy value
7.844,000 into NUMERIC field...
Either copy such values into a temp. table with
On Wed, Jul 11, 2007 at 09:50:25AM -0300, Fernando Madruga Pinheiro wrote:
Hi. I'm having some strange round behaviour when using 4 decimals.
If I use ROUND(1.8947, 2), it should return 1.90, but it does return 1.89.
I asked my math teacher a similar question back in 7th grade:
If you
Fernando Madruga Pinheiro [EMAIL PROTECTED] writes:
If I use ROUND(1.8947, 2), it should return 1.90, but it does return 1.89.
Why do you consider that wrong? It's the closest approximation.
Do you know of any other software that would produce 1.90 from a
similar query?
Rounding to 3 decimal
Hi Tom,
Sorry. After sending to group one friend of mine explained to me how round
works -- not postgresql round, but round in math.
I do not know any software that would produce that output.
I thought that when 1.8947 was rounded to 2 decimal places, 7 would round-up
4, then 5 would round-up
hi all
i downloaded postgres8.2.4 sources , expand and
./configure and install with success.
Now i need one module from contrib directory ,
fuzzystrmatch
cd /postgres/contrib/fuzzymatchstr [ ok ]
make
throws
make
Makefile:15: ../../src/Makefile.global: No such file
or directory
I read the docs but I'm still not sure. If I create a temp table with ON
COMMIT DROP then is that table private to the transaction? In other
words, if the temp table is created in plpgsql stored procedure foo
and foo is executed from different transactions in parallel then each
transaction
On Wed, Jul 11, 2007 at 10:28:25PM +0530, Joshua N Pritikin wrote:
and foo is executed from different transactions in parallel then each
transaction will see its own private temp table, right?
They will see their own private temp tables _no matter what_.
There's no shared temp table support
Hello,
I am restricted to 8.0.7 version of postgresql and I am facing two problems
when trying to build generic auditing function. I went through documentation
http://www.postgresql.org/docs/8.0/interactive/plpgsql-trigger.html
example:
Example 35-3. A PL/pgSQL Trigger Procedure For Auditing
marcelo Cortez [EMAIL PROTECTED] writes:
i downloaded postgres8.2.4 sources , expand and
./configure and install with success.
Now i need one module from contrib directory ,
fuzzystrmatch
cd /postgres/contrib/fuzzymatchstr [ ok ]
make
throws
make
Makefile:15:
Shuo Liu [EMAIL PROTECTED] writes:
Whoa ... that is a whole lot more data than I'm used to seeing in
TopMemoryContext. How many stats dump lines are there exactly (from
here to the crash report)?
OK, I didn't know that was a surprise. There are about 600 stats dump lines
in between.
Well,
On 07/11/07 12:06, Andrew Sullivan wrote:
On Wed, Jul 11, 2007 at 10:28:25PM +0530, Joshua N Pritikin wrote:
and foo is executed from different transactions in parallel then each
transaction will see its own private temp table, right?
They will see their own private temp tables _no matter
On Tue, 2007-07-10 at 12:44 -0700, Ben wrote:
...which I then need to tokenize in order to find which archived wal
files I'll need to keep as part of the backup. For instance, that
output above will result in a WAL file named like so:
Try using pg_xlogfile_name()
Hi, Tom,
Thank you so much for pointing out the problems. The first one seems very silly
:-(. For the second one, I may stay out of trouble if I don't use transform()
at all (I can tolerate some error without transform), am I right?
--- On Wed 07/11, Tom Lane [EMAIL PROTECTED] wrote:
Shuo Liu [EMAIL PROTECTED] writes:
Thank you so much for pointing out the problems. The first one seems very
silly :-(. For the second one, I may stay out of trouble if I don't use
transform() at all (I can tolerate some error without transform), am I right?
Hmm, I wouldn't suggest removing
On Wed, Jul 11, 2007 at 02:36:54PM -0500, Ron Johnson wrote:
Will GLOBAL TEMP tables be added any time soon?
I think there's a recent thread/bunfight about this topic on
-hackers. You may want to draw your own conclusions on the basis of
what you see there -- I'm not willing to speculate :)
Hi,
I'm using the following statement in my plpgsql function
SELECT INTO no_rows COUNT(*) FROM tbl_concurrent;
I have decalred no_rows int4 and initialized it to zero
Running the function throws the following error:
ERROR: syntax error at or near ( at character 13
QUERY: SELECT $1 (*)
Just a word of advice... unless you plan to spend lots of time on your
db (like you want to think about it more than twice a week sort of
thing...), just go with what you have in terms of the distro. We are
running 8.1.4. And it just works, yes, even after all this time! You
are certainly behind
On Jul 11, 2007, at 4:00 PM, Jasbinder Singh Bali wrote:
Hi,
I'm using the following statement in my plpgsql function
SELECT INTO no_rows COUNT(*) FROM tbl_concurrent;
I have decalred no_rows int4 and initialized it to zero
Running the function throws the following error:
ERROR: syntax
-- Original message --
From: Jasbinder Singh Bali [EMAIL PROTECTED]
Hi,
I'm using the following statement in my plpgsql function
SELECT INTO no_rows COUNT(*) FROM tbl_concurrent;
I have decalred no_rows int4 and initialized it to zero
Running the
On Jul 11, 4:00 pm, [EMAIL PROTECTED] (Jasbinder Singh Bali) wrote:
I don't know why isn't count(*) working
Works for me:
create table tbl_concurrent(a int);
insert into tbl_concurrent values (1);
insert into tbl_concurrent values (9);
insert into tbl_concurrent values (4);
create or replace
Jasbinder Singh Bali [EMAIL PROTECTED] writes:
I'm using the following statement in my plpgsql function
SELECT INTO no_rows COUNT(*) FROM tbl_concurrent;
I have decalred no_rows int4 and initialized it to zero
Running the function throws the following error:
ERROR: syntax error at or
Hello,
with help of Bricklen, I have found that the problem is the scope of call
EXECUTE. When this is called it seems to be launched outside of the trigger's
scope and OLD/NEW is not defined. (Manual suggests it)
The remaining question is how to compare OLD.* and NEW.* in generic way for
Here's my table:
Table public.tokens
Column |Type |
Modifiers
---+-
+
token_idx | bigint
Tom Allison [EMAIL PROTECTED] writes:
I have ~250K rows in this table.
the token_idx is referenced in two other tables, both of whom have a
foreign key constraint to ON DELETE CASCADE.
Of the other two tables, one has ~1M rows and the other ~350K rows.
Problem:
Deleting one row can
Tom Lane wrote:
alexander lunyov [EMAIL PROTECTED] writes:
With this i just wanted to say that lower() doesn't work at all on
russian unicode characters,
In that case you're using the wrong locale (ie, not russian unicode).
Check show lc_ctype.
db= SHOW LC_CTYPE;
lc_ctype
--
32 matches
Mail list logo
