Jeff MacDonald wrote:
Hi,
I very rarely have reason to post to this list so I was reluctant to
sign up for such heavy traffic, but I have a few things to bring up
and they're all 'general'
1: Go to the website and type in "now()" into the search box, it will break
Error in query: Unmatched parenthesis
Ta very much - well caught. If no-one on the web team mentions they're
handling it I'll pass it along.
2: On the support page beside pgsql-bugs, it tells us to post in the
bug reporting form, AND signup for 2 mailing lists. I can't possibly
see how this would encourage anyone to want to report a bug if they
have to jump thru these hoops. Just my 2 cents.
Hmm - wasn't sure what you meant here, but I looked at the text and it
does say that:
pgsql-bugs
If you find a bug, please use the bug reporting form. If PostgreSQL
failed to compile on your computer, please report it to pgsql-ports
rather than this list. If you've found a bug in PostgreSQL, please send
it both to this list and also to the pgsql-patches list.
I think that last sentence should probably read: "If you've FIXED a bug
in PostgreSQL..."
The reason you're asked to subscribe to the mailing list is that that is
where the developers will actually read it. You can actually just
subscribe to the list if you're going to hang around, but it's probably
better for a lot of users to have a bug-number they can reference.
3: An actual but that I'll repeat here even tho I've already posted it
as bug # 1938
Not on the lists yet - dare say it'll get there shortly.
Lets say i have a table with a row that looks something like this..
articleposted timestamp default now(),
And yesterday afternoon I did a dump/restore. Now my table reads
article posted | timestamp with time zone | default '2005-10-03
17:14:25.581388-04'::timestamp with time zone
Which means it's interpreting the now() instead of just copying it.
Very strange. I've been around here for a while now and I can't remember
this bug at all (and it would affect me as well as many others). Read on
for what I think it might be though.
Kind of a pain when I just restored 75 databases with many many
"default now()'s" as you can imagine.
Ouch. Not pleasant.
Can't see it in 7.4.x ...
richardh=> CREATE TABLE ts_def_test(a int4, b timestamp with time zone
default now());
CREATE TABLE
richardh=> \d ts_def_test
Table "public.ts_def_test"
Column | Type | Modifiers
--------+--------------------------+---------------
a | integer |
b | timestamp with time zone | default now()
$ pg_dump --schema-only --table=ts_def_test -Urichardh richardh
[snipped irrelevant lines]
CREATE TABLE ts_def_test (
a integer,
b timestamp with time zone DEFAULT now()
);
Could you have done something like:
CREATE TABLE ts_def_test2(a int4, b timestamp with time zone default 'now');
Which gives:
CREATE TABLE ts_def_test2 (
a integer,
b timestamp with time zone DEFAULT '2005-10-05
00:08:05.381034+01'::timestamp with time zone
);
The difference being that 'now' is a literal timestamp (with timezone)
that gets evaluated in your CREATE TABLE statement.
If that's not what it is, have a check on the release notes (in the
reference section of the manual) and see if there's any mention of it.
If it is a bug, I'd guess it's in pg_dump rather than anywhere else, so
it's probably making sure you're running the most recent 7.4.x (or
whatever) and try that pg_dump.
HTH
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
