Re: [GENERAL] Quotes, double quotes...

2013-09-30 Thread hubert depesz lubaczewski
On nie, wrz 29, 2013 at 02:09:54 +0100, António M. Rodrigues wrote: The code is the following: - DO $$ DECLARE i integer; BEGIN FOR i IN (select nn from numeros) LOOP EXECUTE 'create table contagio' || i || ' as SELECT * FROM

Re: [GENERAL] logging statements in PostgreSQL

2013-09-30 Thread Albe Laurenz
Jayadevan M wrote: Thanks for the pointer. I do not really want to log the plans of queries, just the queries, execution time and a couple of other details (database,user). If I use the auto-explain module, it will end up printing the plan for all query execution in the log files? You can

Re: [GENERAL] psql swallowed my BEGIN; on reset... user beware?

2013-09-30 Thread Moshe Jacobson
On Sun, Sep 29, 2013 at 2:18 AM, Ken Tanzer ken.tan...@gmail.com wrote: After restarting the server in another window, I was surprised that my command did not run in a transaction: spc_test_scratch=# BEGIN; DROP VIEW IF EXISTS ptest_mip ; DROP VIEW rent_info; \i create.view.rent_info.sql

Re: [GENERAL] psql swallowed my BEGIN; on reset... user beware?

2013-09-30 Thread Merlin Moncure
On Mon, Sep 30, 2013 at 10:49 AM, Moshe Jacobson mo...@neadwerx.com wrote: On Sun, Sep 29, 2013 at 2:18 AM, Ken Tanzer ken.tan...@gmail.com wrote: After restarting the server in another window, I was surprised that my command did not run in a transaction: spc_test_scratch=# BEGIN; DROP VIEW

Re: [GENERAL] psql swallowed my BEGIN; on reset... user beware?

2013-09-30 Thread Ryan Kelly
On Mon, Sep 09/30/13, 2013 at 11:49:29AM -0400, Moshe Jacobson wrote: On Sun, Sep 29, 2013 at 2:18 AM, Ken Tanzer ken.tan...@gmail.com wrote: After restarting the server in another window, I was surprised that my command did not run in a transaction: spc_test_scratch=# BEGIN; DROP VIEW

Re: [GENERAL] psql swallowed my BEGIN; on reset... user beware?

2013-09-30 Thread Ryan Kelly
On Mon, Sep 09/30/13, 2013 at 11:49:29AM -0400, Moshe Jacobson wrote: On Sun, Sep 29, 2013 at 2:18 AM, Ken Tanzer ken.tan...@gmail.com wrote: After restarting the server in another window, I was surprised that my command did not run in a transaction: spc_test_scratch=# BEGIN; DROP VIEW

[GENERAL] Inconsistent behavior with unnamed columns

2013-09-30 Thread Moshe Jacobson
Why does bool get special treatment? postgres# select 'abc', 1, false; ?column? | ?column? | bool --+--+-- abc |1 | f (1 row) Moshe Jacobson Nead Werx, Inc. | Manager of Systems Engineering 2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339

Re: [GENERAL] Inconsistent behavior with unnamed columns

2013-09-30 Thread Adrian Klaver
On 09/30/2013 01:48 PM, Moshe Jacobson wrote: Why does bool get special treatment? |postgres# select 'abc', 1, false; ?column? | ?column? | bool --+--+-- abc |1 | f (1 row)| Not always: test= select 'abc'::text, 1::int, 'f'; text | int4 | ?column?

Re: [GENERAL] Inconsistent behavior with unnamed columns

2013-09-30 Thread David Johnston
Moshe Jacobson wrote Why does bool get special treatment? postgres# select 'abc', 1, false; ?column? | ?column? | bool --+--+-- abc |1 | f (1 row) It doesn't (at least not as I see things in my client/version - noted below): *SELECT 'abc'::text;* If

Re: [GENERAL] Inconsistent behavior with unnamed columns

2013-09-30 Thread Tom Lane
David Johnston pol...@yahoo.com writes: Moshe Jacobson wrote Why does bool get special treatment? postgres# select 'abc', 1, false; ?column? | ?column? | bool --+--+-- abc |1 | f (1 row) It doesn't (at least not as I see things in my client/version -

Re: [GENERAL] psql swallowed my BEGIN; on reset... user beware?

2013-09-30 Thread Ken Tanzer
you can control this with on error stop directive -- add it to your psqlrc if you want the setting to persist. I hear what you're saying, but wonder about the implications: It sounds like you can't trust your BEGIN to actually start a transaction unless on_error_stop is set The default for

[GENERAL] Postgres replication question :- One master 2 slaves 9.0.10

2013-09-30 Thread akp geek
Hi all - Currently we have set up one master one slave , which working fine. Now we need to replicate to an other slave. The problem we have , the port that we use on primary can not be reached from the new slave. We can't the change the primary port also, because many applications

Re: [GENERAL] Postgres replication question :- One master 2 slaves 9.0.10

2013-09-30 Thread Chris Travers
On Mon, Sep 30, 2013 at 7:14 PM, akp geek akpg...@gmail.com wrote: Hi all - Currently we have set up one master one slave , which working fine. Now we need to replicate to an other slave. The problem we have , the port that we use on primary can not be reached from the new slave.