Re: [GENERAL] foreign keys

2000-08-06 Thread vectro
On Sat, 5 Aug 2000, Bruce Momjian wrote: > > Not to mentions fact that in a few places in docs it's shown as a method > > for copying table "SELECT... INTO" which does not "take" keys with it > > leading to database knwoledge loss. > > That is a good point. SELECT INTO doesn't support constrain

Re: [GENERAL] foreign keys

2000-08-06 Thread Stephan Szabo
On Sun, 6 Aug 2000, Radoslaw Stachowiak wrote: > *** Bruce Momjian <[EMAIL PROTECTED]> [Saturday, 05.August.2000, 19:39 -0400]: > > > Not to mentions fact that in a few places in docs it's shown as a method > > > for copying table "SELECT... INTO" which does not "take" keys with it > > > leading

Re: [GENERAL] foreign keys

2000-08-06 Thread Radoslaw Stachowiak
*** Bruce Momjian <[EMAIL PROTECTED]> [Saturday, 05.August.2000, 19:39 -0400]: > > Not to mentions fact that in a few places in docs it's shown as a method > > for copying table "SELECT... INTO" which does not "take" keys with it > > leading to database knwoledge loss. > > That is a good point.

Re: [GENERAL] Table Design: Timestamp vs time/date

2000-08-06 Thread Tom Lane
Dale Walker <[EMAIL PROTECTED]> writes: > Having a 'timestamp' field 'CCYY-MM-DD HH:MM:SS.SS' or two separate > fields one for time 'HH:MM:SS.SS' and one for Date 'CCYY-MM-DD'. Go for the timestamp. Otherwise you'll be cursing yourself the first time someone wants to know about "all logins betwe

Re: [GENERAL] foreign keys

2000-08-06 Thread Bruce Momjian
> *** Bruce Momjian <[EMAIL PROTECTED]> [Saturday, 05.August.2000, 19:39 -0400]: > > > Not to mentions fact that in a few places in docs it's shown as a method > > > for copying table "SELECT... INTO" which does not "take" keys with it > > > leading to database knwoledge loss. > > > > That is a g

Re: [GENERAL] libperl.so

2000-08-06 Thread Alex Pilosov
Yeah, openbsd ld/ld.so for example will bitch and moan when its asked to do this. (nonPIC code loaded as so). So this is to be used as last resort. On Sat, 5 Aug 2000, Lamar Owen wrote: > Charles Tassell wrote: > > There is also a way to recompile a .a library into a shared > > library. Someth

Re: [GENERAL] Re: Need for rebuilding index after many deletions?

2000-08-06 Thread Tom Lane
>>> With Postgres 6.5.2, if a table has undergone several row deletions, >>> does it make sense/ is it needed to rebuild the index? If you've deleted a large fraction of the rows in the table, dropping and recreating the indexes would be worth doing, because VACUUM by itself won't reclaim unuse