James William Pye 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 BINARY;
> ERRO
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
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
---
Andrew Gierth wrote:
> > "Heikki" == Heikki Linnakangas
> > writes:
>
> Heikki> Oops, you're right. The check is indeed confusing julian
> "Heikki" == Heikki Linnakangas
> 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 fix.
Which reminds me:
Andrew Gierth wrote:
>> "James" == James Pye 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 at
> "James" == James Pye 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=# copy x f
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 > JULIAN
Heikki Linnakangas 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 reasonable multibyte c
Greg Stark wrote:
> On Mon, Aug 31, 2009 at 12:01 PM, Heikki
> Linnakangas 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 encodings.
>
>
On Mon, Aug 31, 2009 at 12:01 PM, Heikki
Linnakangas 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 encodings.
I don't think we even have to
Greg Stark wrote:
> On Mon, Aug 31, 2009 at 9:12 AM, Heikki
> Linnakangas 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 ca
On Mon, Aug 31, 2009 at 9:12 AM, Heikki
Linnakangas 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 casts from integer to "char"
fo
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
13 matches
Mail list logo
