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 ha
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 a
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
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
LowerCaseIdentif
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:
Sent: Wednesday, July 11, 200
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 wi
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 ro
"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 dec
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
Make
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 wi
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" suppor
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
h
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: ../../src/
"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 betw
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 what
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()
http://www.postgresql.org/d
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 re
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 (*) F
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 a
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 er
-- 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
>
> Runni
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 a
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
8.
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
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
alexander,
lc_ctype and lc_collate can be changed only at initdb !
You need to read localization chapter
http://www.postgresql.org/docs/current/static/charset.html
Oleg
On Thu, 12 Jul 2007, alexander lunyov wrote:
Tom Lane wrote:
alexander lunyov <[EMAIL PROTECTED]> writes:
With this i
Oleg Bartunov wrote:
alexander,
lc_ctype and lc_collate can be changed only at initdb !
You need to read localization chapter
http://www.postgresql.org/docs/current/static/charset.html
Yes, i knew about this, but i thought maybe somehow it can be changed
onthefly.
... (10 minutes later)
Yes
34 matches
Mail list logo
