Re: [GENERAL] Dynamic SQL - transition from ms to pg

2014-01-05 Thread Michael Paquier
On Mon, Jan 6, 2014 at 2:13 PM, Erik Darling wrote: > Hi, > > I've been developing for MS SQL around four years. I'm starting out with > some work in Postgresql next week, and I'd like to know if there's any > equivalent way to do something like this (from my word press) > > http://sqldriver.word

[GENERAL] Dynamic SQL - transition from ms to pg

2014-01-05 Thread Erik Darling
Hi, I've been developing for MS SQL around four years. I'm starting out with some work in Postgresql next week, and I'd like to know if there's any equivalent way to do something like this (from my word press) http://sqldriver.wordpress.com/2013/12/09/generating-inserts-dynamically/ My question

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
That is not an option either. This is for a publicly released extension and I'm really not going to go requiring another scripting language be installed, especially an untrusted one. -- Keith Fiske Database Administrator OmniTI Computer Consulting, Inc. http://www.keithf4.com On Sun, Jan 5, 201

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Pavel Stehule
2014/1/6 Keith Fiske > That fixed it! In the example and my original as well. Thank you very much! > > And wow that was incredibly misleading where the cast was supposed to go > going by the error given and when it was thrown. That EXECUTE statement > works perfectly fine, seeing as the v_record

Re: [GENERAL] authentication failure

2014-01-05 Thread Jayadevan M
I am able to login as postgres with password from the same machine. So it is not an expiry issue (as you too concluded). Output from strace is about 500 lines. I am pasting what I feel may be relevant. I hope this will be useful. execve("/usr/pgsql-9.3/bin/psql", ["psql", "-h", "localhost"], [/*

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Adrian Klaver
On 01/05/2014 08:43 PM, Keith Fiske wrote: I can't remove the quote_literal() because the value could potentially be a string, time, or number. Without the loop, quote_literal() handles the variable being any one of those types without any issues and quotes (or doesn't) as needed. Well I tried

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Adrian Klaver
On 01/05/2014 08:34 PM, Keith Fiske wrote: Actually, that doesn't work right. Gives weird results when the column is an integer Example: keith=# select min(col1), max(col1) from partman_test.time_static_table_p2014_01_01; min | max -+- 86 | 100 (1 row) keith=# select min(col1::tex

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
I can't remove the quote_literal() because the value could potentially be a string, time, or number. Without the loop, quote_literal() handles the variable being any one of those types without any issues and quotes (or doesn't) as needed. -- Keith Fiske Database Administrator OmniTI Computer Consu

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Adrian Klaver
On 01/05/2014 08:34 PM, Keith Fiske wrote: Actually, that doesn't work right. Gives weird results when the column is an integer Example: keith=# select min(col1), max(col1) from partman_test.time_static_table_p2014_01_01; min | max -+- 86 | 100 (1 row) keith=# select min(col1::tex

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Adrian Klaver
On 01/05/2014 08:23 PM, Keith Fiske wrote: That fixed it! In the example and my original as well. Thank you very much! And wow that was incredibly misleading where the cast was supposed to go going by the error given and when it was thrown. That EXECUTE statement works perfectly fine, seeing as

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
Actually, that doesn't work right. Gives weird results when the column is an integer Example: keith=# select min(col1), max(col1) from partman_test.time_static_table_p2014_01_01; min | max -+- 86 | 100 (1 row) keith=# select min(col1::text), max(col1::text) from partman_test.time_stat

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
That fixed it! In the example and my original as well. Thank you very much! And wow that was incredibly misleading where the cast was supposed to go going by the error given and when it was thrown. That EXECUTE statement works perfectly fine, seeing as the v_record variable got its assignment with

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Adrian Klaver
On 01/05/2014 06:31 PM, Keith Fiske wrote: Running into an issue trying to dynamically create some SQL statements in a plpgsql function. The function below is as simple an example I can make to reproduce the error. The first loop works without any issues, but the second throws an error. CREATE O

Re: [GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
Sorry, forgot to include that I've tested this on PostgreSQL versions 9.2.6 and 9.3.2 and same thing happens on both. -- Keith Fiske Database Administrator OmniTI Computer Consulting, Inc. http://www.keithf4.com On Sun, Jan 5, 2014 at 9:31 PM, Keith Fiske wrote: > Running into an issue trying

[GENERAL] Planning error in dynamic string creation in plpgsql

2014-01-05 Thread Keith Fiske
Running into an issue trying to dynamically create some SQL statements in a plpgsql function. The function below is as simple an example I can make to reproduce the error. The first loop works without any issues, but the second throws an error. CREATE OR REPLACE FUNCTION testing_record() RETURNS v

Re: [GENERAL] help interpreting pg_stat_user_index view values

2014-01-05 Thread Erik Darling
You could also look into a filtered index that perhaps only covers dates earlier than a certain point in time where regular performance wouldn't be hindered. But Gavin is absolutely right otherwise. On Jan 5, 2014 5:22 PM, "Sergey Konoplev" wrote: > > On Sun, Jan 5, 2014 at 2:19 PM, Gavin Flower

Re: [GENERAL] help interpreting pg_stat_user_index view values

2014-01-05 Thread Sergey Konoplev
On Sun, Jan 5, 2014 at 2:19 PM, Gavin Flower wrote: > On 06/01/14 11:08, Sergey Konoplev wrote: > [...] > >> An index might be considered as useless when there were no idx scans for >> the significantly long period. However it might be non-trivial to define >> this period. Eg. one have a query bui

Re: [GENERAL] help interpreting pg_stat_user_index view values

2014-01-05 Thread Gavin Flower
On 06/01/14 11:08, Sergey Konoplev wrote: [...] An index might be considered as useless when there were no idx scans for the significantly long period. However it might be non-trivial to define this period. Eg. one have a query building an annual report that uses this index and the period here

Re: [GENERAL] help interpreting pg_stat_user_index view values

2014-01-05 Thread Sergey Konoplev
On Fri, Jan 3, 2014 at 10:53 PM, wrote: > Index name idx_scan idx_tup_read idx_tup_fetch > idx1 1000 > 0 > idx2 100 2000 > idx3 100 200

Re: [GENERAL] authentication failure

2014-01-05 Thread Adrian Klaver
On 01/05/2014 07:47 AM, Jayadevan M wrote: With md5 psql psql: FATAL: password authentication failed for user "postgres" with trust psql -h localhost psql (9.3.2) Type "help" for help. back to md5 psql -h localhost psql: FATAL: password authentication failed for user "postgres" But... find

Re: [GENERAL] authentication failure

2014-01-05 Thread Tom Lane
I wrote: > Perhaps the postgres user has a password that's marked as expired > in pg_authid.rolvaliduntil? Ah, no, scratch that: a look at the code shows the backend doesn't check rolvaliduntil until after the client has given a valid password. Seems like psql *must* be getting a password from som

Re: [GENERAL] authentication failure

2014-01-05 Thread Tom Lane
Jayadevan M writes: > back to md5 > psql -h localhost > psql: FATAL: password authentication failed for user "postgres" > [ but there's no .pgpass file ] Perhaps the postgres user has a password that's marked as expired in pg_authid.rolvaliduntil? Try select rolname, rolvaliduntil from pg_authi

Re: [GENERAL] authentication failure

2014-01-05 Thread Adrian Klaver
On 01/05/2014 07:47 AM, Jayadevan M wrote: With md5 psql psql: FATAL: password authentication failed for user "postgres" with trust psql -h localhost psql (9.3.2) Type "help" for help. back to md5 psql -h localhost psql: FATAL: password authentication failed for user "postgres" Just noticed

Re: [GENERAL] authentication failure

2014-01-05 Thread Jayadevan M
With md5 psql psql: FATAL: password authentication failed for user "postgres" with trust psql -h localhost psql (9.3.2) Type "help" for help. back to md5 psql -h localhost psql: FATAL: password authentication failed for user "postgres" But... find / -name .pgpass $ env | grep PG PGPORT=1234

Re: [GENERAL] file system level backup

2014-01-05 Thread Adrian Klaver
On 01/04/2014 06:41 PM, zach cruise wrote: CCing list: So is there anything in the Windows system logs? > looks like file system level backups don't work well on windows because they get corrupted during transfer. Whoa, how did we get to that conclusion? > as a safety, i had a

Re: [GENERAL] authentication failure

2014-01-05 Thread Adrian Klaver
On 01/04/2014 08:46 PM, Jayadevan M wrote: Log entries for 3 situations - 2 successful and one failed attempt - From non-chroot, shell user postgres 2014-01-05 10:11:58 IST [17008]: [2-1] user=postgres,db=postgres LOG: connection authorized: user=postgres database=postgres 2014-01-05 10:12:03

Re: [GENERAL] file system level backup

2014-01-05 Thread Sameer Kumar
I am not sure if you have already answered it and I have somehow missed it: - Are these 'a' and 'b' on two different servers? ( I think they are on different servers) - Did you stop the server on 'b' before you replaced the files and attempted a startup? > thanks. it doesn't help. i also tried pg_

Re: [GENERAL] authentication failure

2014-01-05 Thread Sameer Kumar
On Sun, Jan 5, 2014 at 6:45 PM, Jayadevan wrote: > Sameer Kumar wrote > > This only tells that there is one instance running! > > > > There could be multiple PostgreSQL installations. And I guess that is > what > > Tom meant here. > > I doubt that was what Tom meant. Anyway, we can see from the er

Re: [GENERAL] authentication failure

2014-01-05 Thread Jayadevan
Sameer Kumar wrote > This only tells that there is one instance running! > > There could be multiple PostgreSQL installations. And I guess that is what > Tom meant here. I doubt that was what Tom meant. Anyway, we can see from the error that the request did reach the server. Sameer Kumar wrote