Re: [BUGS] Bug in date_part()
Thanks for the reply Tom Lane, and Tom Lockhart. On my 7.0.3:
phil=# select '4/1/2001'::date::timestamp;
?column?
2001-03-31 23:00:00-08
(1 row)
This was built from source downloaded from the primary FTP site link
on www.postgresql.org.
[cartret@Stimpy signup]$ psql --version
psql (PostgreSQL) 7.0.3
This machine is a redhat 5.0 based machine, although it's gone through
a lot of software updates (mostly by hand).
I have not tried the latest CVS/developer code, so perhaps it is
fixed. Is there a chance that this bug is actually outside of
postgresql? Like in a shared lib or something? Like I noted, this is
an old RH install with updates, but very likely has some old libs and
stuff on it.
BTW- I've solved my issue by using a perl function to figure out the
dow, so this follow up is purely for your assistance in squashing the
bug if it hasn't already.
Thanks!
Phil
On Wed, Jan 17, 2001 at 12:13:20PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > edge=# select date_part('dow','4/1/2001'::date)::int4;
> > ?column?
> > --
> > 6
> > (1 row)
>
> Seems to be fixed in current sources:
>
> regression=# select date_part('dow','4/1/2001'::date)::int4;
> ?column?
> --
> 0
> (1 row)
>
>
> I think this is a side-effect of the known 7.0 bug in date-to-timestamp
> conversion on DST transition days. Check out
>
> select '4/1/2001'::date::timestamp;
>
> regards, tom lane
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[EMAIL PROTECTED] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
[BUGS] Install/regression test instructions don't work.
Downloaded V7.0.3 from latest area. Followed build instructions on my Alpha Linux box. Regression test instructions do not work as postmaster (or something similarly named) isn't running. If this is part of Postgresql, you need to say how to start it. If its not part of postgresql, you need to say where to get it as you do for gmake. I can't proceed until I pass this step, so I'm waiting for a response. Thanks. Kevin Koch
Re: [BUGS] pgsql-loophole-request@postgresql.org does not exist
long ago gone ... if you want to get on a list to post to, without being
swamped with email, send a 'subscribe-nomail' to the -request address for
the list ... especially great for those using news to post to the lists :)
On Wed, 17 Jan 2001, Jason Schroeder wrote:
> http://www.postgresql.org/bugs/index.php indicates that the address
> [EMAIL PROTECTED] exists. It does not. ;-)
>
> The original message was received at Wed, 17 Jan 2001 19:00:28 -0500 (EST)
> from [209.43.202.2]
>
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> (reason: 550 5.1.1 User unknown)
>
>- Transcript of session follows -
> ... while talking to localhost:
> >>> RCPT To:
> <<< 550 5.1.1 User unknown
> 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
[BUGS] minor fault report
Hi, when I ./pg_dump -?, the text that's shown ends: "...if no database name is not supplied..." bye, Bert
Re: [BUGS] Re: Bug in date_part()
Ah, I think I understand the trouble now. It's good it's fixed for
the next release. And, as predicted, I'm running in a DST zone
(/etc/localtime -> ../usr/share/zoneinfo/US/Pacific)
Thanks for the quick diagnosis!
Phil
On Wed, Jan 17, 2001 at 09:07:34PM -0500, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> Query to reproduce the bug (7.0.3):
> >> edge=# select date_part('dow','4/1/2001'::date)::int4;
> >> --
> >> 6
>
> > I'm not seeing this on my 7.0.2 RPM installation, or on my from-cvs
> > current sources (dow for April 1 comes up as zero, as you would expect).
>
> I get the right answer from current sources, and the wrong one on 7.0.2.
> It's ye olde date-to-timestamp-off-an-hour-at-DST-boundary problem.
> Are you not running in a USA timezone?
>
> regards, tom lane
--
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
[EMAIL PROTECTED] -- http://www.netroedge.com/~phil
PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
[BUGS] ascii() picks up sign bit past CHAR value 127
ascii() returns negative ASCII values? ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description ascii() picks up sign bit past CHAR value 127 Long Description The lack of an UNISIGNED INT1 attribute type forces those of us who need a positive numeric byte type to use CHAR. The ascii() function ostensibly returns the numeric ASCII value of the corresponding CHAR attribute value - but once you get beyond the 0-127 ACCII character value range, the ascii() function starts picking up the active high order bit as a sign bit. This is not too surprising but it is a bit bizarre since I tend to think of character encoding standards having the option of using the 127-255 character values. Just in case anyone was wondering, there are many good reasons to have an unsigned int1 type. For example, I am using one byte numbers to define the bytes of an int4 (or int8) word. The first byte partitions up the word's value range into 256 ranges. Within each of these the second word adds up to 256 value range partitions - and so on. This encodes a breadth (<256) and depth (<4/8) limited hierarchy designation as a single int4/int8 attribute. This designation makes it fast to find items/records that fall under any node/sub-tree within the original hierarchical designation/category/etc. In other words, this is a trick for *VERY* fast, albeit strictly limited, transitive closure. First, the int4/int8 word is BTREE indexed. Then this index is range scanned to find all the items that appear in/under any node/sub-tree of the original hierarchy. That sure beats something like Oracle's dreadfully slow CONNECT BY syntax. At any rate, we need to deal with unsigned numeric bytes - and PostgreSQL doesn't make that easy. I imagine many folks have already thought about extending the basic types with unsigned variants. Perhaps I have missed support for unsigned types in the documentation (I don't think this is SQL std)? I imagine many folks have thought about supporting a one byte integer to round out the basic type suite (for many reasons). I'd like to add my voice to calls for both. Thanks Sample Code select ascii(ichar(127)); select ascii(ichar(128)); select ascii(ichar(129)); select ascii(ichar(130)); No file was uploaded with this report
Re: [BUGS] ascii() picks up sign bit past CHAR value 127
[EMAIL PROTECTED] writes: > The lack of an UNISIGNED INT1 attribute type forces those of us who > need a positive numeric byte type to use CHAR. The ascii() function > ostensibly returns the numeric ASCII value of the corresponding CHAR > attribute value - but once you get beyond the 0-127 ACCII character > value range, the ascii() function starts picking up the active high > order bit as a sign bit. This is not too surprising but it is a bit > bizarre since I tend to think of character encoding standards having > the option of using the 127-255 character values. If you use gcc, you could probably recompile the backend with -funsigned-char to make ascii() work the way you want. On a machine where char is considered signed, I'm not sure that ascii()'s behavior is wrong ... could argue that either way I suppose. regards, tom lane
