On Fri, Jun 01, 2007 at 09:07:10PM +0300, [EMAIL PROTECTED] wrote:
>
> Hi Andrew,
>
> I must admit I don't really understand what you say. I don't know what
> SRF stand for, and what you say about generic case is not clear to me,
> sorry.
Sorry, it stands for set returning function. I thought
Hi
has anyone done any work on comparing schemas?
I'm trying to automatically propagate changes in a master schema to
child schemas. All schema changes will originate at master. Currently
child schemas are in the same database, but in the future might be in
different databases (clusters?).
tha
Hi Andrew,
I must admit I don't really understand what you say. I don't know what
SRF stand for, and what you say about generic case is not clear to me,
sorry.
My idea is that using a parameter table allows me to keep using a view,
which is optimized for instance when used against a WHERE cond
On Fri, Jun 01, 2007 at 08:07:46PM +0300, [EMAIL PROTECTED] wrote:
> I've contemplated reusing an awful hack from my Access era, namely using
> a single-rowed table to store the parameter and joining the view on it.
> The parameter would be updated before the view is called; this would
> work but w
Hi all,
first let me tell you that this nice "whole-row comparison" feature of
postgres 8.2 allowed me to create a versionned database model very
neatly. The SQL statement that inserts in the destination table only
the one rows that are new or that have changed since last time is very
simply wri
