Hello!
I use Postgre-9.3.5 on windows7 x64.
I use simple trigger for store some statistic data, it code:
SELECT field IN variable FROM table WHERE ...;
IF FOUND THEN
UPDATE table SET field = ...;
ELSE
INSERT INTO table (field) VALUES(value);
END IF;
RETURN NULL;
This trigger added as FOR
Michael,
Appreciate your quick response. Thank you.
I would like to know how is the Shared Disk Failover replication achieved
if it is not possible to share the data directory ? I am referring to the
1st solution in the mentioned link,
Hi,
On Fri, 2014-11-14 at 02:57 -0700, dineshkaarthick wrote:
I would like to know how is the Shared Disk Failover replication
achieved if it is not possible to share the data directory ? I am
referring to the 1st solution in the mentioned link,
dineshkaarthick wrote:
I would like to know how is the Shared Disk Failover replication achieved
if it is not possible to share the data directory ? I am referring to the
1st solution in the mentioned link,
http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html
You
Brilliantov Kirill Vladimirovich wrote:
I use Postgre-9.3.5 on windows7 x64.
I use simple trigger for store some statistic data, it code:
SELECT field IN variable FROM table WHERE ...;
IF FOUND THEN
UPDATE table SET field = ...;
ELSE
INSERT INTO table (field) VALUES(value);
END IF;
Albe Laurenz wrote on 11/14/2014 01:28 PM:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Table with statistic:
CREATE TABLE trassa.cpu_load_stat
(
id serial NOT NULL,
device integer NOT NULL,
cpu
Brilliantov Kirill Vladimirovich wrote:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Table with statistic:
CREATE TABLE trassa.cpu_load_stat
(
id serial NOT NULL,
device integer NOT NULL,
cpu
Hello
I have a table, and I want to always supply predicates in a BETWEEN format.
If all data is to be returned, then the FROM and TO values of the
BETWEEN are set to low hex value, and high hex value.
Sometimes this is not returning rows, here's an example:
e5iso=# create table t1 (col1
Actually I find this returns my row:
select col1 from t1 where col1 BETWEEN E'\x01\x01\x01' AND
E'\xFF\xFF\xFF' or col1=E'\x20';
Why does x'202020' match an equality condition on E'\x20' ?
Is there some auto trimming going on?
This is PostgreSQL 9.3.5 on Linux
On 14 November 2014 11:41, Gary
Hello,
As i am new to postgresql and django. please help me to acheive the
following.
I have created a database with some tables and i want to encrypt the
data in database tables, so please someone guide me how to do it.?
i want to encrypt the data and also decrypt through django,
On 11/14/2014 03:24 AM, Albe Laurenz wrote:
Brilliantov Kirill Vladimirovich wrote:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Table with statistic:
CREATE TABLE trassa.cpu_load_stat
(
id serial NOT
Gary Cowell gary.cowell+pg...@gmail.com writes:
e5iso=# create table t1 (col1 character(3));
CREATE TABLE
e5iso=# insert into t1 values('AAA');
INSERT 0 1
e5iso=# insert into t1 values('000');
INSERT 0 1
e5iso=# insert into t1 values(' ');
INSERT 0 1
e5iso=# insert into t1 values(' x
On 11/13/2014 5:56 PM, Guyren Howe wrote:
On Nov 13, 2014, at 2:28 PM, Andy Colson a...@squeakycode.net wrote:
I want to do something that is perfectly satisfied by an hstore column. *Except* that
I want to be able to do fast (ie indexed) , etc comparisons, not just
equality.
From what I
Adrian Klaver wrote on 11/14/2014 05:15 PM:
Actually I think there is in the table the trigger is on. From the
original post:
SQL statement INSERT INTO trassa.cpu_load (device, device_timestamp,
cpu, value) VALUES(5,'1970-01-02 06:02:38',0,6),(5,'1970-01-02
06:02:38',1,0),(5,'1970-01-02
On 11/14/2014 07:23 AM, Brilliantov Kirill Vladimirovich wrote:
Adrian Klaver wrote on 11/14/2014 05:15 PM:
Actually I think there is in the table the trigger is on. From the
original post:
SQL statement INSERT INTO trassa.cpu_load (device, device_timestamp,
cpu, value) VALUES(5,'1970-01-02
Albe Laurenz wrote on 11/14/2014 01:28 PM:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Yours,
Laurenz Albe
Table with original data trassa.cpu_load:
CREATE TABLE trassa.cpu_load
(
id serial NOT NULL,
On 11/14/2014 07:32 AM, Brilliantov Kirill Vladimirovich wrote:
Albe Laurenz wrote on 11/14/2014 01:28 PM:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Yours,
Laurenz Albe
Just approaching caffeine level
On 11/14/2014 07:32 AM, Brilliantov Kirill Vladimirovich wrote:
Albe Laurenz wrote on 11/14/2014 01:28 PM:
You should post the table definition and the whole trigger; the error
message seems to refer to things you omitted in your quote.
Yours,
Laurenz Albe
Turns out I was not at a
On 11/14/2014 2:24 AM, Albe Laurenz wrote:
dineshkaarthick wrote:
I would like to know how is the Shared Disk Failover replication achieved
if it is not possible to share the data directory ? I am referring to the
1st solution in the mentioned link,
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as `/etc/postgresql/VERSION/main/postgresql.conf`
however, the pg_upgrade script expects it in the `datadir`.
the simple
Jonathan Vanasco-7 wrote
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as `/etc/postgresql/VERSION/main/postgresql.conf`
however, the pg_upgrade script expects it in
On 11/14/2014 11:10 AM, Jonathan Vanasco wrote:
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as `/etc/postgresql/VERSION/main/postgresql.conf`
however, the pg_upgrade
David G Johnston wrote
Jonathan Vanasco-7 wrote
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as
`/etc/postgresql/VERSION/main/postgresql.conf`
however, the
David G Johnston wrote:
David G Johnston wrote
It would make more sense for the Debian packagers people to write a
pg_upgradecluster wrapper like they have done for the other key programs.
Note it appears there is a pg_upgradecluster program, but it doesn't appear
to a wrapper for the
David G Johnston wrote
David G Johnston wrote
Jonathan Vanasco-7 wrote
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as
On 11/14/14 2:10 PM, Jonathan Vanasco wrote:
I ran into an issue migrating from 9.1 to 9.3 on ubuntu using pg_upgrade
the default ubuntu package, and the one from postgresql.org, both store
`postgresql.conf` in etc as `/etc/postgresql/VERSION/main/postgresql.conf`
however, the pg_upgrade
On 11/14/14, 10:09 AM, Adrian Klaver wrote:
Trigger update_cpu_load_stat added to table trassa.cpu_load:
CREATE TRIGGER update_cpu_load_stat_trigger
AFTER INSERT
ON trassa.cpu_load_stat
FOR EACH ROW
EXECUTE PROCEDURE trassa.update_cpu_load_stat();
Another run through showed that
27 matches
Mail list logo
