| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Leon <leon(at)udmnet(dot)ru> |
| Cc: | bughunters <pgsql-bugs(at)postgreSQL(dot)org> |
| Subject: | Re: [BUGS] 'Default' troubles again. This time with time :))) |
| Date: | 1999-07-18 20:11:10 |
| Message-ID: | 12650.932328670@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Leon <leon(at)udmnet(dot)ru> writes:
> Tom! I tested your method of creating table with
> create table ww (aa int4, bb timestamp default text 'now'),
> and it didn't work either! (BTW, this is exactly the way docs suggest
> doing it.) See? I promised to deliver a real bug and I did it! :)))
By golly, you're right. It works as advertised for a DATETIME field,
which is the case I'd been testing. But for a TIMESTAMP field the
constant gets pre-coerced anyway :-(. Wonder why ... will look into
it, since I'm busy hacking on that part of the system now.
> Yes, docs mumble something about 'cacheable' and 'non-cacheable'
> functions, but it is not clear to me how Postgres discerns them.
The proiscachable field in table pg_proc is presumably supposed to
tell this. Doesn't look like it's set in an intelligent manner
for most of the built-in functions though. I don't think it has
anything to do with the bug for TIMESTAMP...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Unprivileged user | 1999-07-19 08:47:05 | General Bug Report: psql does report failed SQL commands as executed |
| Previous Message | Leon | 1999-07-18 16:29:31 | Re: [BUGS] 'Default' troubles again. This time with time :))) |