Thread: Reasonable
It seems that this below is causing some strange problems with our
PostgreSQL database. We're running it on a FreeBSD 3.2 box, PG version 6.5.1
(with a 6.5.2 upgrade planned really soon)
These seems good to me, I can't see any errors yet when I try to enter it
into a database, it either locks up psql (the client) or just does nothing
at all..
As you can see from the format it is from a pg_dump of another datatable, I
just added a few things and was going to turn around and create another
table, then the problems started.. If the error is something simple then I
do apologize for wasting anyone's time, however I can't seem to see anything
wrong..
Thanks!!
The query that's giving me fits :
CREATE TABLE "user_applicant_search" ( "app_id" int4, "created" datetime, "createdcond" varying(2),
"status" character varying(1) default 'Active', "statuscond" character varying(1) default '=',
"firstname"character varying(25), "firstnamecond" character varying(2) default '=', "lastname" character
varying(25), "lastnamecond" character varying(2) default '=', "address1" character varying(30),
"address1cond"character varying(2) default '=', "address2" character varying(30), "city" character
varying(20), "citycond" character varying(8) default 'starts', "state" character varying(10),
"statecond"character varying(2) default '=', "email" character varying(50), "emailcond character varying(8)
default'starts', "clearance" character varying(20), "clearancecond" character varying(8) default 'starts',
"language" character varying(20), "languagecond" character varying(8) default 'starts', "dateavailable"
date, "dateavailablecond" varying(2) default '=', "employed" bool, "employedcond" character varying(1)
default'X', "sic1" int4, "sic1cond" character varying(2) default '>=', "skill1" int4,
"skill1cond"character varying(2) default '>=', "coregroup" character varying(10), "coregroupcond" character
varying(8)default 'starts', "objective" character varying(80), "objectivecond" character varying(8) default
'starts', "degree1" character varying(30), "degree1cond" character varying(8) default 'starts',
"d1type"character varying(6), "d1typecond" character varying(2) default '=', "d1discipline" character
varying(30), "d1disciplinecond" character varying(3) default '=', "d1date" int4, "d1datecond"
charactervarying(2) default '=', "d1gpa" float, "d1gpacond" character varying(2) default '=',
"salary"character varying(40), "salarycond" character varying(8) default 'starts', "salarycurrent" int4,
"salarycurrentcond" character varying(2) default '=', "salarydesire" int4, "salarydesirecond" character
varying(2)default '=', "salarymin" int4, "salarymincond" character varying(2) default '=', "license"
charactervarying(50), "licensecond" character varying(8) default 'starts', "locstate" character varying(2),
"locstatecond" character varying(8) default 'contains');
Again, thanks!!
- Mitch
"0100110100110000010101000100001101001000"
At 17:32 +0200 on 05/10/1999, Mitch Vincent wrote:
...
> "createdcond" varying(2),
> "status" character varying(1) default 'Active',
> "statuscond" character varying(1) default '=',
> "firstname" character varying(25),
> "firstnamecond" character varying(2) default '=',
> "lastname" character varying(25),
> "lastnamecond" character varying(2) default '=',
> "address1" character varying(30),
> "address1cond" character varying(2) default '=',
> "address2" character varying(30),
> "city" character varying(20),
> "citycond" character varying(8) default 'starts',
...
It's hard to know when you don't tell us which error message you got, but
my guess is as follows: Most of these fields are defined using the syntax
"fieldname" character varying(N)...
But I seem to detect a couple of fields, "createdcond" above, as well as
"dateavailablecond". Are those the fields you added? For some reason, they
are defined as:
"fieldname" varying(N)...
Without the character keyword. On a cursory look this would not work.
Another potential problem is your use of a six-letter long default for a
varying(1) field ("status").
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
Herouth Maoz <herouth@oumail.openu.ac.il> writes:
> Another potential problem is your use of a six-letter long default for a
> varying(1) field ("status").
6.5.* has some problems with wrong-length default values for char(n) and
varchar(n) fields. There is a slightly klugy fix in place for char(n),
but a cursory test suggests that it doesn't catch the varchar case.
The consequences aren't as bad as they were for char(n): you just get
a field value that's longer than it's supposed to be. Workaround:
give a correct default value.
This is all fixed properly in current sources (6.6/7.0-to-be).
regards, tom lane
On Tue, Oct 05, 1999 at 11:32:50AM -0400, Mitch Vincent wrote: ... > The query that's giving me fits : > > > > CREATE TABLE "user_applicant_search" ( > "app_id" int4, > "created" datetime, > "createdcond" varying(2), > "status" character varying(1) default 'Active', > "statuscond" character varying(1) default '=', > "firstname" character varying(25), > "firstnamecond" character varying(2) default '=', > "lastname" character varying(25), > "lastnamecond" character varying(2) default '=', > "address1" character varying(30), > "address1cond" character varying(2) default '=', > "address2" character varying(30), > "city" character varying(20), > "citycond" character varying(8) default 'starts', > "state" character varying(10), > "statecond" character varying(2) default '=', > "email" character varying(50), > "emailcond character varying(8) default 'starts', ... ^^^^^^ Don't you need a closing "? Albert. -- --------------------------------------------------------------------------- Post an / Mail to / Skribu al: Albert Reiner<areiner@tph.tuwien.ac.at> ---------------------------------------------------------------------------