Richard ~
Let me zoom out for a moment, for the bigger picture.
As you have inferred, what I'm trying to do is develop a history-preserving
table ("my_data" in the example that started this thread). *Most* user
programs would see and manipulate this table as if it contained only the
current rows
On Mon, 19 Dec 2005 09:54:49 -0700
Michael Fuhr <[EMAIL PROTECTED]> threw this fish to the penguins:
> On Mon, Dec 19, 2005 at 11:06:12AM -0500, george young wrote:
> > create table new_tab(name text, id int, permits text[]);
> >
> > -- I insert one row per name:
> > insert into new_tab select di
On Mon, Dec 19, 2005 at 11:06:12AM -0500, george young wrote:
> create table new_tab(name text, id int, permits text[]);
>
> -- I insert one row per name:
> insert into new_tab select distinct name,id,cast('{}' as text[]) from old_tab;
>
> Now I want to fold all the 'permits' values into the new
Emil Rachovsky wrote:
>
> Hi,
> Can anyone show me a simple way of creating an index
> in PostGre like that:
> create index indName on someTable(someIntColumn DESC)
> ?
Not using that particular syntax, but you can do that if you create the
appropiate operator classes. Note that if you want to u
Richard Huxton writes:
> Ken Winter wrote:
>> Can a trigger be written on a *view*?
> There's nothing for them to fire against even if you could attach the
> trigger.
Currently we reject CREATE TRIGGER on a view, but it occurred to me the
other day that that could be relaxed, at least for BEFOR
Ken Winter wrote:
Richard ~
Thanks for your response.
Can a trigger be written on a *view*? I can't find anything in the
PostgreSQL docs that answers this question.
There's nothing for them to fire against even if you could attach the
trigger. I suppose you could have a statement-level trig
[PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.1]
I'm trying to convert a column from a traditional relational form to an array:
create table old_tab(name text, id int, permits text);
newschm3=# select * from old_tab order by name;
name | id | permits
--
Hi,
Can anyone show me a simple way of creating an index
in PostGre like that:
create index indName on someTable(someIntColumn DESC)
?
Thanks In Advance,
Emil
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http:
Richard ~
Thanks for your response.
Can a trigger be written on a *view*? I can't find anything in the
PostgreSQL docs that answers this question.
I originally wrote these actions (described in my original message) as a
trigger on my base table, but then realized I was getting in deeper and
dee
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Sun, Dec 18, 2005 at 10:08:22PM -0500, Tom Lane wrote:
>> Just for the record, that behavior is seriously broken: it violates
>> MVCC if any of the deleted tuples are still visible to anyone else.
> Does it remove tuples that VACUUM FULL wouldn't?
On Mon, Dec 19, 2005 at 08:46:39AM -0500, Lane Van Ingen wrote:
> Thanks, that helped.
>
> Please answer 2 other related questions, if you would:
> (1) What must I do to 'Be prepared for serialization failures' (how to
> detect, how to handle)?
> Do you have a sample?
You'll get an error.
O Lane Van Ingen έγραψε στις Dec 19, 2005 :
> Thanks, that helped.
>
> Please answer 2 other related questions, if you would:
> (1) What must I do to 'Be prepared for serialization failures' (how to
> detect, how to handle)?
> Do you have a sample?
Look at
http://www.postgresql.org/docs/7.
Thanks, that helped.
Please answer 2 other related questions, if you would:
(1) What must I do to 'Be prepared for serialization failures' (how to
detect, how to handle)?
Do you have a sample?
(2) Also, I am assuming that the effect of all of this is to just force
transactions to wait in lin
O Lane Van Ingen έγραψε στις Dec 19, 2005 :
> I am using PL/SQL functions on Windows 2003, version 8.0.1.
>
> I have not used explicit PostgreSQL LOCKing before, but I need some advice
> on how properly to use some explicit locking. I think that duplicate key
> violations I am now getting are the
On Sun, Dec 18, 2005 at 10:08:22PM -0500, Tom Lane wrote:
>
> Just for the record, that behavior is seriously broken: it violates
> MVCC if any of the deleted tuples are still visible to anyone else.
Does it remove tuples that VACUUM FULL wouldn't? I always thought it
did essentially the same th
I am using PL/SQL functions on Windows 2003, version 8.0.1.
I have not used explicit PostgreSQL LOCKing before, but I need some advice
on how properly to use some explicit locking. I think that duplicate key
violations I am now getting are the result.
I want to force transactions being used to up
Ken Winter wrote:
This rule is supposed to (1) cause an update directed to the view
"my_data_now" to be made to the underlying table "my_data", (2) reset the
"effective_date_and_time" of that row to 'now', (3) insert a record
containing the old values into "my_data", and (4) expire that "old" rec
17 matches
Mail list logo
