[GENERAL] error handling. How to?

2001-07-09 Thread Janning Vygen
Hi, i try do achieve that my database checks every entry on insert and update and returns german error messages, so my frontend knows what's wrong and can show some reasonable error messages to the user. i wrote a trigger who checks BEFORE every insert and updtae and returns error messages if

Re: [GENERAL] error handling. How to?

2001-07-09 Thread Richard Huxton
From: "Janning Vygen" <[EMAIL PROTECTED]> > one of my problems: > if i have a value like bool or int2 and the frontend is html and just takes > the input from a textfield, the backend returns an error before executing the > trigger beacuse the values cant be parsed into the correct type. > > But

Re: [GENERAL] PostgreSQL perl / libpq.so.2 problem - again :(

2001-07-09 Thread Lamar Owen
On Saturday 07 July 2001 11:39, Justin Clift wrote: > Are you familiar with Symantec Ghost? Yes. Is there now a version that doesn't require Windows installed? :-) I own the Windows version. I've used it numerous times for that. However, I prefer to simply unlock a drive slide and slide a ne

Re: [GENERAL] ODBC 3.0 functions (UCASE, LCASE, etc.)

2001-07-09 Thread Bruce Momjian
This is clearly a good idea. It is easy to create SQL functions as synonyms for existing functions. You can even alter the arguments. I would encourage anyone who wants to start coding an SQL file of compatibility functions. > On Thu, 3 May 2001, Bruce Momjian wrote: > > > > > This sounds g

Re: [GENERAL] orphaned RI constraints

2001-07-09 Thread Stephan Szabo
On Mon, 9 Jul 2001, Jan Wieck wrote: > Somazx Interesting wrote: > > At 01:30 PM 7/6/2001 -0700, you wrote: > > >To fix it, you should be able to use DROP TRIGGER on the appropriate > > >triggers that were created (you can find these through a select on > > >pg_trigger, using the tgargs to find

Re: [GENERAL] trigger: NEW/OLD-error or nothing happens

2001-07-09 Thread Jan Wieck
Knut Suebert wrote: > Joe Conway schrieb: > > > OLD does not make sense on an insert because there is no "OLD" data for a > > brand new row. Similarly, there is no "NEW" data during a delete. See > > http://www.postgresql.org/idocs/index.php?plpgsql-trigger.html > > Makes sense, thanks. And at the

Re: [GENERAL] Re: [DOCS] QUERY - Including the new LDP PostgreSQL HOWTO in the main PostgreSQL distribution

2001-07-09 Thread Mitch Vincent
> For a long time, I thougt HOWTO is docuement for "quick start". Isn't it? I'm not sure there is an understood meaning of what a HOWTO actually it. It's an explanation of how to do something, I guess... Generally I've found (as in your example) that it's putting software together and making it w

Re: [GENERAL] Transactions in rules..

2001-07-09 Thread Jan Wieck
Fabrizio Mazzoni wrote: > Can i use transactions in rules?? > I was trying something like: > > create rule x_test as > on insert to view1 > do instead > ( >begin; >insert into test1 values (new.a,new.b); >insert into test2 values (new.c,new.d); >commit; > ); > > But when i give thi

Re: [GENERAL] problems with rules and views

2001-07-09 Thread Tom Lane
"Fabrizio Mazzoni" <[EMAIL PROTECTED]> writes: > Considering that my view has about 35 columns, is there a way to write a > rule that does a batch update..?? Something like: > create rule xxx as > on update to yyy <-- my view > do instead > update to xxx,qqq,zzz; <-- tables from which the view is

Re: [GENERAL] fmgr_info: function 2714160: cache lookup failed

2001-07-09 Thread Jan Wieck
Steve Wampler wrote: > > Can someone explain to me what this error is and how to avoid it? > (Results from an INSERT through JDBC on 7.1.2 with RH Linux). You must have droppend a function that was referenced by another object (view, operator, aggregate, whatnot). Recrea

[GENERAL] [PATCH] Partial indicies again

2001-07-09 Thread Martijn van Oosterhout
Well, getting closer. Maybe I should start version numbering the patches? Things changed in this version: * As Tom Lane pointed out, what to do with EXTEND INDEX. I've decided to remove it since there is no defined syntax for it and you cannot make an index more restrictive with it. Since th

Re: [GENERAL] [PATCH] Partial indicies again

2001-07-09 Thread Tom Lane
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: >> I suspect you need to run cnfify after and-ing together the predicate >> and index quals. clauselist_selectivity assumes it's working on >> cnf'ified expressions. > OK. Do I need to worry about that function destroying either of the input > l

Re: [GENERAL] Re: Backups WAS: 2 gig file size limit

2001-07-09 Thread Doug McNaught
[HACKERS removed from CC: list] Joseph Shraibman <[EMAIL PROTECTED]> writes: > Doing a dumpall for a backup is taking a long time, the a restore from > the dump files doesn't leave the database in its original state. Could > a command be added that locks all the files, quickly tars them up, th

Re: [GENERAL] Re: Backups WAS: 2 gig file size limit

2001-07-09 Thread Joseph Shraibman
Doug McNaught wrote: > > [HACKERS removed from CC: list] > > Joseph Shraibman <[EMAIL PROTECTED]> writes: > > > Doing a dumpall for a backup is taking a long time, the a restore from > > the dump files doesn't leave the database in its original state. Could > > a command be added that locks al

Re: [GENERAL] Re: Backups WAS: 2 gig file size limit

2001-07-09 Thread Tom Lane
Joseph Shraibman <[EMAIL PROTECTED]> writes: > Could a command be added that locks all the files, quickly tars them > up, then releases the lock? pg_ctl stop tar cfz - $PGDATA >someplace pg_ctl start There is no possibility of anything less drastic, if you want to ensure that the database files

Re: [GENERAL] Re: Backups WAS: 2 gig file size limit

2001-07-09 Thread Thomas Lockhart
> > Have you observed otherwise? > Yes. Specifically timestamps are dumped in a way that (1) they lose > percision (2) sometimes have 60 in the seconds field which prevents the > dump from being restored. The loss of precision for timestamp data stems from conservative attempts to get consistant

[GENERAL] Re: postgres slower than grep?

2001-07-09 Thread Allan Engelhardt
I could only be botherd to try a million lines, but my results from 7.1.2 are below. Basically: 1. I find about 50% database storage overhead in this case. That's not completely silly, considering this is structured data, but seems a little high. I don't know the internal structures well eno

[GENERAL] Known problem with HASH index?

2001-07-09 Thread Allan Engelhardt
Is there a known problem with HASH type index in PostgreSQL 7.1.2 4PGDG on Red Hat Linux 7.1 (2.4.2 kernel)? I can't find a lot of documentation, but this is what I observe: [playpen]$ dropdb test; createdb test; psql -f create_table.sql test; psql -c "COPY clients FROM '/tmp/input.txt';" te

Re: [GENERAL] any disadvantage of PostgeSQL on Windows

2001-07-09 Thread GH
On Tue, Jul 10, 2001 at 11:30:05AM +0800, some SMTP stream spewed forth: > Would appreciate a lot if anyone could tell me if there is any > disadvantage/performance issue in using PostgeSQL on windows. I know of no disadvantages that are not a direct result of Windows. Such things as the shared

Re: [GENERAL] Qn on best way to upgrade from 7.0.2 to 7.0.3 on production database

2001-07-09 Thread GH
On Mon, Jul 09, 2001 at 05:52:21PM +0800, some SMTP stream spewed forth: [...] > therefore I need to upgrade to 7.0.3. > > the doc says to do dump/restore when upgrading the database. however, since pg_dump >has problem with timestamp data, how am I going to restore back the data after >upgrad