Re: [GENERAL] COPY error with null date

On 21st March 2014, Ashmita Jain Wrote: >It is taking date as an empty string. >Try defining the empty field as '\N' in your source file. '\N' in copy source file always results into an empty string (unless something written in new line), which is correct only. So COPY from such source file will

[GENERAL] Do we have a range of SQLSTATE codes assigned for custom use?

Hi all With RAISE supporting user-defined SQLSTATEs, and EXCEPTION ... WHEN supporting matching them, shouldn't we explicitly declare a range of SQLSTATEs as reserved for custom use? Right now, there's nothing in http://www.postgresql.org/docs/current/static/errcodes-appendix.html to tell a user

Re: [GENERAL] DB alias ?

On 03/23/2014 06:22 PM, Tim Uckun wrote: How can this be combined with other commands. For example pgsql doesn't like this psql service=test1 -d test_database -c "some command" But it would like this: http://www.postgresql.org/docs/9.3/static/app-psql.html "An alternative way to specify conn

Re: [GENERAL] DB alias ?

How can this be combined with other commands. For example pgsql doesn't like this psql service=test1 -d test_database -c "some command" the PGSERVICE=test1 psql blah blah works but seems cumbersome. Why isn't there a psql --service=blah option? On Thu, Jan 24, 2013 at 9:48 PM, Guillaume Lela

Re: [GENERAL] Upgrading from 9.2 to 9.3 causes performance degradation

On Mon, Mar 24, 2014 at 10:58 AM, Álvaro Nunes Lemos Melo < al_nu...@atua.com.br> wrote: Hi, > > Recently, I've been trough a datacenter migration, and in this operation > I'd also upgraded my PostgreSQL version from 9.2 to 9.3. My new hardware is > slightly better than the old one, but the Postgr

Re: [GENERAL] Upgrading from 9.2 to 9.3 causes performance degradation

On Mar 23, 2014, at 7:58 PM, Álvaro Nunes Lemos Melo wrote: ... > the whole system is slower. > > Below is my data, and I really hope we can find what is happening, or I'll > have to downgrade to 9.2 and wait for 9.4 release. I think this is a good starting place: http://wiki.postgresql.org/w

Re: [GENERAL] Upgrading from 9.2 to 9.3 causes performance degradation

On 03/23/2014 04:58 PM, Álvaro Nunes Lemos Melo wrote: Hi, Recently, I've been trough a datacenter migration, and in this operation I'd also upgraded my PostgreSQL version from 9.2 to 9.3. My new hardware is slightly better than the old one, but the PostgreSQL performance has shown degradatio

[GENERAL] Upgrading from 9.2 to 9.3 causes performance degradation

Hi, Recently, I've been trough a datacenter migration, and in this operation I'd also upgraded my PostgreSQL version from 9.2 to 9.3. My new hardware is slightly better than the old one, but the PostgreSQL performance has shown degradation in the whole system. Trying to figure out what could b

Re: [GENERAL] plpython timestamp without time zone, showing up as text instead of timestamp

On 03/23/2014 09:47 AM, jared wrote: On Sun, Mar 23, 2014 at 12:11 PM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: Intended: http://www.postgresql.org/__docs/9.3/interactive/plpython-__data.html FY

Re: [GENERAL] plpython timestamp without time zone, showing up as text instead of timestamp

On Sun, Mar 23, 2014 at 12:11 PM, Adrian Klaver wrote: > > Intended: > > http://www.postgresql.org/docs/9.3/interactive/plpython-data.html > > FYI, it would be a good idea to include the Postgres version. plpython has > been undergoing a lot of changes recently, so it would help to peg where > you

Re: [GENERAL] plpython timestamp without time zone, showing up as text instead of timestamp

On 03/23/2014 08:19 AM, jared wrote: My full function works fine as a standalone python script, but I was having trouble getting it to work in Posgres. Outside of Postgres it worked fine (because I was feeding in lists of dates to test on). The I did the script with psycopg2 calling in the belo

[GENERAL] plpython timestamp without time zone, showing up as text instead of timestamp

My full function works fine as a standalone python script, but I was having trouble getting it to work in Posgres. Outside of Postgres it worked fine (because I was feeding in lists of dates to test on). The I did the script with psycopg2 calling in the below table and it worked fine. (in the do

Re: [GENERAL] Default operator class for data type boolean for access method gist is missing

På søndag 23. mars 2014 kl. 09:59:27, skrev Andreas Kretschmer < akretsch...@spamfence.net >: Andreas Joseph Krogh wrote: > I'm trying to define the following exclusion-constraint >   > > alter table my_table add EXCLUDE USING gist (is_default WITH =, dater

Re: [GENERAL] Default operator class for data type boolean for access method gist is missing

På søndag 23. mars 2014 kl. 08:13:43, skrev Emre Hasegeli mailto:e...@hasegeli.com>>: 2014-03-23, Andreas Joseph Krogh < andr...@officenet.no >: I'm trying to define the following exclusion-constraint   alter table my_table add EXCLUDE USING gist (is_defaultWITH =, da

Re: [GENERAL] Default operator class for data type boolean for access method gist is missing

Andreas Joseph Krogh wrote: > I'm trying to define the following exclusion-constraint >   > > alter table my_table add EXCLUDE USING gist (is_default WITH =, > daterange(valid_from, valid_to, '[)') WITH &&) WHERE (is_default = true); > >   > But it fails with: > ERROR:  data type boolean has n

Re: [GENERAL] Default operator class for data type boolean for access method gist is missing

2014-03-23, Andreas Joseph Krogh : > I'm trying to define the following exclusion-constraint > > > *alter table *my_table *add EXCLUDE USING gist *(is_default *WITH *=, > *daterange*(valid_from, valid_to, *'[)'*) *WITH *&&) *WHERE *(is_default = > *true*); > > is_default should not be in the ind