Re: a bug, the bugs list, and how to break the website - Mailing list pgsql-general
From | Richard Huxton |
---|---|
Subject | Re: a bug, the bugs list, and how to break the website |
Date | |
Msg-id | 43430CB3.4000709@archonet.com Whole thread Raw |
In response to | a bug, the bugs list, and how to break the website search. (Jeff MacDonald <bignose@gmail.com>) |
Responses |
Re: a bug, the bugs list, and how to break the website
|
List | pgsql-general |
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
pgsql-general by date: