Subject: a bug, the bugs list, and how to break the website search.

From: Jeff MacDonald <[email-masked]>
Date: Tue, 4 Oct 2005 15:46:53 -0400

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

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.

3: An actual but that I'll repeat here even tho I've already posted it
as bug # 1938

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.

Kind of a pain when I just restored 75 databases with many many
"default now()'s" as you can imagine.

Thanks in advance.

--
Jeff MacDonald
http://www.halifaxbudolife.ca
http://www.nintai.ca

---

From: Tom Lane <[email-masked]>
Date: Tue, 04 Oct 2005 19:10:13 -0400

> have to jump thru these hoops. Just my 2 cents.

The above would better be reported to pgsql-www; perhaps the website
maintainers will notice it here, or perhaps they won't.  (But I've
cc'd that list, so you need not report it again.)

As for the second point, you can *either* subscribe to pgsql-bugs (and
email your report) or use the report form; you need not do both.  If
the website gives the wrong impression then it should be fixed.

> 17:14:25.581388-04'::timestamp with time zone

I don't believe that your default was now().  It was probably more
like
	articleposted timestamp default 'now'
which is a thinko specifically warned against in the documentation.

			regards, tom lane

---

From: Richard Huxton <[email-masked]>
Date: Wed, 05 Oct 2005 00:13:55 +0100

> 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.

> 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

Not on the lists yet - dare say it'll get there shortly.

> 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.

> "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

---

From: Robert Treat <[email-masked]>
Date: Tue, 4 Oct 2005 20:35:40 -0400

> I think that last sentence should probably read: "If you've FIXED a bug

I think I concur with you on that one Richard... fixed in CVS, will go live on 
next site build. Thanks. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL