James William Pye li...@jwp.name wrote:
Need a special case for the infinities as well?
postgres=# create table foo (d date);
postgres=# INSERT INTO foo VALUES ('infinity');
postgres=# COPY foo TO '/Users/jwp/foo.copy' WITH BINARY;
postgres=# COPY foo FROM '/Users/jwp/foo.copy' WITH
On Nov 10, 2009, at 9:54 AM, Bruce Momjian wrote:
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
Heikki Oops, you're right. The check is indeed confusing julian day
Heikki numbers, with epoch at 23th of Nov 4714 BC, with
Heikki postgres-reckoning day numbers, with
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
---
Andrew Gierth wrote:
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
Heikki Oops, you're right. The check is
Andrew Gierth wrote:
James == James Pye li...@jwp.name writes:
James Is the new date_recv() constraint actually correct?
No, it's not:
Oops, you're right. The check is indeed confusing julian day numbers,
with epoch at 23th of Nov 4714 BC, with postgres-reckoning day numbers,
with epoch
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
Heikki Oops, you're right. The check is indeed confusing julian day
Heikki numbers, with epoch at 23th of Nov 4714 BC, with
Heikki postgres-reckoning day numbers, with epoch at 1th of Jan
Heikki 2000. Thanks, will
On Aug 31, 2009, at 1:12 AM, Heikki Linnakangas wrote:
...
Is the new date_recv() constraint actually correct?
[looking at the result 0 part, at least]
src/backend/utils/adt/date.c
...
+ /* Limit to the same range that date_in() accepts. */
+ if (result 0 || result
James == James Pye li...@jwp.name writes:
James Is the new date_recv() constraint actually correct?
No, it's not:
regression=# create table x (a date);
CREATE TABLE
regression=# insert into x values ('1999-01-01');
INSERT 0 1
regression=# copy x to '/tmp/tst.dmp' binary;
COPY 1
regression=#
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Greg Stark wrote:
Just make the textual representation of char be \xxx (or perhaps we
could switch to \xHH now) if the value isn't a printable ascii
character. As long as char reads that in properly it doesn't matter
if it's not a
Greg Stark wrote:
On Mon, Aug 31, 2009 at 12:01 PM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, perhaps we should follow what we did to chr() and ascii(): map the
integer to unicode code points if the database encoding is UTF-8, and
restrict the range to 0..127 for other
After the thread started by Andrew McNamara a while ago:
http://archives.postgresql.org/message-id/e419f08d-b908-446d-9b1e-f3520163c...@object-craft.com.au
the question was left hanging if other binary recv functions are missing
sanity checks that the corresponding text input functions have, and
On Mon, Aug 31, 2009 at 9:12 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
The most notable of these is the change to char datatype. The patch
tightens it so that it no longer accepts values 127 with a multi-byte
database encoding.
That doesn't sound right to me. We accept
Greg Stark wrote:
On Mon, Aug 31, 2009 at 9:12 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
The most notable of these is the change to char datatype. The patch
tightens it so that it no longer accepts values 127 with a multi-byte
database encoding.
That doesn't sound
On Mon, Aug 31, 2009 at 12:01 PM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, perhaps we should follow what we did to chr() and ascii(): map the
integer to unicode code points if the database encoding is UTF-8, and
restrict the range to 0..127 for other multi-byte
13 matches
Mail list logo
