You can also use LISTEN/NOTIFY.
On Tue, Dec 1, 2009 at 6:25 PM, Bret bret_st...@machinemanagement.com wrote:
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Steve Atkins
Sent: Tuesday, December 01, 2009 9:44 AM
pg_dump dumps data first and then the constraints (including FK) so
there shouldn't be any problems when you import the dump.
On Wed, Dec 2, 2009 at 2:16 AM, Helio Campos Mello de Andrade
helio.cam...@gmail.com wrote:
Hi guys,
- I'm having a problem when i want to make a backup of my
Speaking of timestamps, I think it would be convenient to have a
single-word alias for timestamp with time zone. This is the date
type I use almost exclusively and its name is annoyingly big.
On Sat, Nov 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Eduardo Piombino drak...@gmail.com
From
http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
Another issue to keep in mind is that in POSIX time zone names,
positive offsets are used for locations west of Greenwich.
On Sun, Nov 29, 2009 at 2:08 AM, seil...@so-net.net.tw wrote:
The target
How about:
IF date_trunc('month',NEW.effective_date)=date_trunc('month',now()) THEN
.
On Tue, Nov 24, 2009 at 7:22 AM, Michal Szymanski dy...@poczta.onet.pl wrote:
In our DB we create partition table for each month (our naming
convetion is follow , and I would like to create
MySQL had the following syntax available:
`updated_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update
CURRENT_TIMESTAMP
I wonder supporting this syntax would speed things up a little bit.
Here's a simple benchmark about the situation we are discussing here:
There are 2 tables:
SELECT * FROM (SELECT *,row_number() OVER (ORDER BY letztespeicherung
DESC) FROM rfmitzeit) t WHERE row_number=1
On Fri, Nov 20, 2009 at 5:31 AM, Massa, Harald Armin c...@ghum.de wrote:
id_bf, wert, letztespeicherung:
98, 'blue', 2009-11-09
98, 'red', 2009-11-10
now I have a
,
letztespeicherung DESC;
My guess is that the latter will perform better but you should do your
own testing.
On Fri, Nov 20, 2009 at 5:36 AM, silly silly8...@gmail.com wrote:
SELECT * FROM (SELECT *,row_number() OVER (ORDER BY letztespeicherung
DESC) FROM rfmitzeit) t WHERE row_number=1
and how would I use DISTINCT ON for this query? Please bear in mind,
that there is more then one id_bf (just stopped the sample data with
one of them)
I posted the answer more than hour ago:
SELECT DISTINCT ON (id_rf) * FROM rfmitzeit ORDER BY id_rf,
letztespeicherung DESC;
The equivalent
You could try to prepare a query like this:
select name from foo where id=any($1);
and then pass the array of integers as $1 (although, I don't know how
you can do that as I've never used the C interface of libpq).
On Fri, Nov 13, 2009 at 1:34 AM, Matt Sanchez matt-sanc...@comcast.net
How about using replication instead of incremental backups?
On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson ahodg...@simkin.ca wrote:
On Tuesday 10 November 2009, akp geek akpg...@gmail.com wrote:
So Is it always good to have the backup using PG_dump instead of PITR or
a combination of both
I
I have the following definitions:
--
create type mytype as (x integer, y integer);
create table foo(
a mytype primary key,
b integer
);
create table bar(
a mytype references foo
);
insert into foo values((0,0)::mytype,0);
In 8.4, the sequence value is copied only when INCLUDING DEFAULTS is
specified. Otherwise, only the not null constraint is copied. I think
this is the most reasonable behavior and I don't see why it should
have been explicitly stated in the manual.
On Fri, Oct 30, 2009 at 8:44 AM, Mark Morgan
Suppose that you have a query, say $sql_query, which is very
complicated and produces many rows. Which of the following is going to
be faser:
$sql_query OFFSET 3000 LIMIT 12;
or
BEGIN;
DECLARE cur1 CURSOR FOR $sql_query;
MOVE 3000 IN cur1;
FETCH 12 FROM cur1;
COMMIT;
2009/10/26 Grzegorz Jaśkiewicz gryz...@gmail.com:
On Mon, Oct 26, 2009 at 10:30 AM, silly silly8...@gmail.com wrote:
Suppose that you have a query, say $sql_query, which is very
complicated and produces many rows. Which of the following is going to
be faser:
$sql_query OFFSET 3000
On Mon, Oct 26, 2009 at 10:28 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
silly escribió:
2009/10/26 Grzegorz Jaśkiewicz gryz...@gmail.com:
On Mon, Oct 26, 2009 at 10:30 AM, silly silly8...@gmail.com wrote:
Suppose that you have a query, say $sql_query, which is very
16 matches
Mail list logo