If a column type is being changed with USING (NULL) clause,
NOT NULL constraint seems not to be checked:
[EMAIL PROTECTED] CREATE table test (x integer not null);
CREATE TABLE
[EMAIL PROTECTED] INSERT INTO test VALUES (1);
INSERT 0 1
[EMAIL PROTECTED] ALTER TABLE test ALTER x TYPE boolean USING (N
(sorry if it's a dup)
In 7.4.3, if I rename a column which references another table,
constraint trigger fails on update or delete from main table.
There are a couple of similar (and about rename table itself) reports
for 7.0, 7.1 (as Tom Lane said, rename table is fixed in 7.2), but I
see no more
In 7.4.3, if I rename a column which references another table,
constraint trigger fails on update or delete from main table.
There are a couple of similar (and about rename table itself) reports
for 7.0, 7.1 (as Tom Lane said, rename table is fixed in 7.2), but I
see no more reports since 2001.
H
Consider the following example for 7.4.3
% cat test.sql
CREATE SCHEMA test_schema;
SET search_path TO test_schema;
CREATE TABLE test_table (
x serial,
s bigint
) WITHOUT OIDS;
CREATE FUNCTION test_update_s() RETURNS trigger AS '
BEGIN
SELECT INTO NEW.s sum(x) F
On Sat, Jul 24, 2004 at 01:56:02AM +0400, Alexander M. Pravking wrote:
> But the following works:
>
> [EMAIL PROTECTED] SET search_path TO test_schema;
> SET
> [EMAIL PROTECTED] INSERT INTO test_table DEFAULT VALUES ;
> INSERT 0 1
> [EMAIL PROTECTED] SET search_path TO p
As been said, in 7.4.5 CIDR data type has been accepted values with
non-zero bits to the right of >24-bit mask:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg00081.php
In CVS head src/backend/utils/adt/network.c (1.54) has a fix by Bruce,
but 7.4.6 still has 1.47.2.1 with no fix.
I wonde
On Fri, Nov 12, 2004 at 11:37:24AM -0500, Bruce Momjian wrote:
> Alexander M. Pravking wrote:
> >
> > As been said, in 7.4.5 CIDR data type has been accepted values with
> > non-zero bits to the right of >24-bit mask:
> >
> > http://archives.postgresql
If I don't specify time zone either in config or using "SET TimeZone"
first, "SET TimeZone" inside a transaction isn't rolled back. System
time zone is actually Europe/Moscow. Here's an example:
[EMAIL PROTECTED] SELECT current_setting('TimeZone'), now();
current_setting | now
--
Docs say: Only the database owner or a superuser can rename a database;
non-superuser owners must also have the CREATEDB privilege.
Looks like a superuser must have CREATEDB too:
[EMAIL PROTECTED] SELECT usesuper, usecreatedb from pg_user where usename =
'fduch';
usesuper | usecreatedb
