Re: [BUGS] Default values for nulls not being set.
> "Donald Fraser" <[EMAIL PROTECTED]> writes:
> > I have a major problem with DEAFAULT values:
>
> Consider attaching a default to the view column. As-is, its default
> is NULL (and I can't see any good argument for the factory default
> being anything else).
What would be nice is when you don't specify a default on the view, the default
from the table is used.
That way, for most cases, you would only need to specify the default in one
place and not for every view...
regards Don.
> tt=# INSERT INTO vu_tbl_test (id, s_desc) VALUES('2', 'View insert test');
> ERROR: ExecInsert: Fail to add null value in not null attribute b_disabled
> tt=# alter table vu_tbl_test alter column b_disabled set default '0';
> ALTER TABLE
> tt=# INSERT INTO vu_tbl_test (id, s_desc) VALUES('2', 'View insert test');
> INSERT 0 1
> tt=#
>
> regards, tom lane
>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Default values for nulls not being set.
"Donald Fraser" <[EMAIL PROTECTED]> writes: > What would be nice is when you don't specify a default on the view, the default > from the table is used. What table? You seem to have an extremely narrow-minded concept of what a view is. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Default values for nulls not being set.
> "Donald Fraser" <[EMAIL PROTECTED]> writes: > > What would be nice is when you don't specify a default on the view, the default > > from the table is used. > > What table? You seem to have an extremely narrow-minded concept of what > a view is. > > regards, tom lane In the above I was referring to columns that have a direct relationship with an underlying table. Obviously when a column does not have this relationship then a default from a table cannot be used. If have I overlooked something fundamental about views that makes this idea sound ridiculous then I apologise for my ignorance. Regards, Donald Fraser ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] setting time zone during a transaction causes time warp
Thanks for the quick response! I haven't had a chance to test the patch yet (this is being built by an automated system, so hand-patching is a bit tough, but I'll adapt the patch to apply cleanly when I have some spare time... or just upgrade to the latest version), but I just wanted you to know that I really appreciate the fast and thorough responses. ...Robert Tom Lane <[EMAIL PROTECTED]> 02/20/2003 12:28 AM To: Robert Haas/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] Fax to: Subject: Re: [BUGS] setting time zone during a transaction causes time warp "Robert Haas" <[EMAIL PROTECTED]> writes: > While using PostgreSQL 7.2.3, I discovered that if I set the time zone > during the transaction, "now" takes on an incorrect value for the > remainder of that transaction. The problem seems to be restricted to the result of 'now'::timestamptz, and not now() or 'now'::timestamp without time zone. I've applied the attached patch to 7.3 --- it would probably work in 7.2 as well, although I think you'd have to hand-patch because of the difference in the nearby HAVE_INT64_TIMESTAMP #ifdefs. regards, tom lane *** src/backend/utils/adt/datetime.c~ Tue Jan 28 20:09:03 2003 --- src/backend/utils/adt/datetime.c Thu Feb 20 00:19:50 2003 *** *** 1242,1250 case DTK_NOW: tmask = (DTK_DATE_M | DTK_TIME_M | DTK_M(TZ)); *dtype = DTK_DATE; ! GetCurrentTimeUsec(tm, fsec); ! if (tzp != NULL) ! *tzp = CTimeZone; break; case DTK_YESTERDAY: --- 1242,1248 case DTK_NOW: tmask = (DTK_DATE_M | DTK_TIME_M | DTK_M(TZ)); *dtype = DTK_DATE; ! GetCurrentTimeUsec(tm, fsec, tzp); break; case DTK_YESTERDAY: *** *** 1958,1964 case DTK_NOW: tmask = DTK_TIME_M; *dtype = DTK_TIME; ! GetCurrentTimeUsec(tm, fsec); break; case DTK_ZULU: --- 1956,1962 case DTK_NOW: tmask = DTK_TIME_M;
[BUGS] 7.3 pg_atoi action
PG Development Team, I would first like to commend all of you on the fantastic service you provide the general public. My first and only complaint is the recent modification to the action pg_atoi( ) takes on empty string sets. (7.3 modification). If possible, could we rollback this change on 7.4 with maybe a compilation option? Thank you, Mark Lane
Re: [BUGS] Installtion error
[Mahesh-Ss-Computer:~] ampleuser% /Library/PostgresqL/bin/pg_ctl -D /users/ampleuser/data -l logfile start postmaster successfully started Postgres will actually be spitting the error to a file called "logfile", while saying it was successful to STDOUT. Your error is in there. Alex -- alex avriette, unix geek for hire http://envy.posixnap.net/ [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Installtion error
Dear sir,
Sir last one week i am try to install PostgreSQL in
Mac os x 10.2 .I dowm loaded PostgreSQL 7.3 from net
and i installed it in 'ampleuser', my login (in
dir:Library/PostgreSQL).
After that i set the paths in follwing manner.And it
successfully starting the postmaster also.But when i
try to create the database its giving the error.
Sir what is the error and plez give me solution
for it.
--
Mahesh-Ss-Computer:/Library/PostgreSQL] root# chown
ampleuser /Library/PostgreSQL/data
Mahesh-Ss-Computer:/Library/PostgreSQL] root# su -l
ampleuser
Mahesh-Ss-Computer:~] ampleuser%
[Mahesh-Ss-Computer:~] ampleuser% setenv PATH
${PATH}:/Library/PostgreSQL/bin
[Mahesh-Ss-Computer:~] ampleuser% setenv PGDATA
/users/ampleuser/data
[Mahesh-Ss-Computer:~] ampleuser%
/Library/PostgresqL/bin/pg_ctl -D
/users/ampleuser/data -l logfile start
postmaster successfully started
[Mahesh-Ss-Computer:~] ampleuser% createdb test
psql: could not connect to server: No such file or
directory
Is the server running locally and accepting
connections on Unix domain socket
"/tmp/.s.PGSQL.5432"?
createdb: database creation failed
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
visit http://in.tv.yahoo.com
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] 7.3 pg_atoi action
[EMAIL PROTECTED] writes: > My first and only complaint is the recent modification to the action > pg_atoi( ) takes on empty string sets. (7.3 modification). > If possible, could we rollback this change on 7.4 with maybe a compilation > option? Now that we've bitten the bullet of making it do what it should have done all along, we're quite unlikely to reverse course. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
