On Monday 23 Jun 2003 10:09 am, Tomasz Myrta wrote:
> Dnia 2003-06-23 10:54, Użytkownik Richard Huxton napisał:
> > Hmm - I think your problem is going to come before that. Any time you do
> > an INSERT, PostgreSQL is going to need to know the types of all the
> > columns involved.
> >
> > For this
Dnia 2003-06-23 10:54, Użytkownik Richard Huxton napisał:
Hmm - I think your problem is going to come before that. Any time you do an
INSERT, PostgreSQL is going to need to know the types of all the columns
involved.
For this sort of thing, I try to keep all the related bits (initial function,
On Monday 23 Jun 2003 9:39 am, Tomasz Myrta wrote:
> Dnia 2003-06-23 10:29, Użytkownik Richard Huxton napisał:
> > Look into views - you'll need to provide triggers to handle the
> > update/inserts.
>
> I think view won't change too much - there is not too much difference for
> this case between cr
Dnia 2003-06-23 10:29, Użytkownik Richard Huxton napisał:
Look into views - you'll need to provide triggers to handle the
update/inserts.
I think view won't change too much - there is not too much difference for this
case between creating view and empty table with trigger returning null.
I was th
On Sunday 22 Jun 2003 10:23 pm, Tomasz Myrta wrote:
> Hi
> I have another virtual problem, currently without any examples ;-)
>
> Let's say we have some pl/pgsql function which puts result into table1.
> This flat table must be normalized and put into table2. Sometimes 1 row
> from table1 = 1 row f
Hi
I have another virtual problem, currently without any examples ;-)
Let's say we have some pl/pgsql function which puts result into table1.
This flat table must be normalized and put into table2. Sometimes 1 row from
table1 = 1 row from table2, but sometimes 1 row from table1= 3 rows from table2
