"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> create table junk (val integer not null, val2 integer);
> create table junk_child () inherits (junk_1);
> alter table junk_child alter column val drop not null;
> insert into junk_child (val2) values (1);
> pg_dump -t junk -t junk_child
> pg_restore/p
The following bug has been logged online:
Bug reference: 3973
Logged by: Alex Hunsaker
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Linux
Description:pg_dump using inherited tables do not always restore
Details:
create table junk (val
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I found this bug comes from the definition of WHITESPACE
> characters in pg_ctl.c. WHITESPACE is defined as folows:
>#define WHITESPACE "\f\n\r\t\v"
> In fact, WHITESPACE does not contain whilespace (0x20) :-(
Ooops :-(
> I attach a patch to fix
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Jacky Leng wrote:
>> --Create table t(a int) with oids;
>> --create unique index it on t(oid);
>> --insert 4G-16384 rows into t;
> ... Therefore: don't do that.
Indeed. It might be a good idea if that loop had a
CHECK_FOR_INTERRUPTS, though.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Return type of hash* functions is just 32 bits. I wonder if that's wide
>> enough
>> to avoid accidental collisions? Depends on the application of course...
> Oh, I missed that you were suggesting a UN
On Wed, Feb 20, 2008 at 12:21:03PM +0100, Francisco Olarte Sanz wrote:
> On Wednesday 20 February 2008, Gregory Stark wrote:
>
> > Unless you need cryptographic security I would not suggest using MD5. MD5
> > is intentionally designed to take a substantial amount of CPU resources to
> > calculate.
Maxime Carbonneau wrote:
> with a database encoded with UTF8, I cannot insert into a varchar(100)
> column the letter œ (\u0x0153). It gives me: "ERROR: function 59015
> returned NULL"
What's function 59015? Try a
select proname from pg_proc where oid = 59015;
--
Alvaro Herrera
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>
>>> As others have pointed out, CREATE UNIQUE INDEX i ON ((md5(column)) is a
>>> pretty
>>> good work-around.
>>
>> Unle
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
As others have pointed out, CREATE UNIQUE INDEX i ON ((md5(column)) is a pretty
good work-around.
Unless you need cryptographic security I would not suggest using MD5. MD5 is
intentionally designed to take a substantial amo
On Wednesday 20 February 2008, Gregory Stark wrote:
> Unless you need cryptographic security I would not suggest using MD5. MD5
> is intentionally designed to take a substantial amount of CPU resources to
> calculate.
I thought it was the exact opposite, quoting from RFC1321:
The MD5 algorithm i
Jacky Leng wrote:
e.g.
--Create table t(a int) with oids;
--create unique index it on t(oid);
--insert 4G-16384 rows into t;
--insert into t values(1);
As all oids has been used, GetNewObjectId will never find a usable Oid,
so.
GetNewObjectId doesn't try to guarantee uniqueness. You w
e.g.
--Create table t(a int) with oids;
--create unique index it on t(oid);
--insert 4G-16384 rows into t;
--insert into t values(1);
As all oids has been used, GetNewObjectId will never find a usable Oid,
so.
---(end of broadcast)---
TIP
The following bug has been logged online:
Bug reference: 3972
Logged by: Maxime Carbonneau
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Linux
Description:ERROR: function 59015 returned NULL
Details:
with a database encoded with UTF8,
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> As others have pointed out, CREATE UNIQUE INDEX i ON ((md5(column)) is a
> pretty
> good work-around.
Unless you need cryptographic security I would not suggest using MD5. MD5 is
intentionally designed to take a substantial amount of CPU resourc
Juho Saarikko wrote:
I suggest implementing unique hash indexes and automatically creating one
(and turning the b-tree index into a non-unique one) when a large value is
inserted to fix this. Alternatively, fix b-trees so they can handle large
values; however, a hash index should be far more effi
15 matches
Mail list logo
