Thank you Stephan, for the quick reply.
Please, do you know if your fixes will be available soon,
or are they already in the development release or any of the production
releases ?
> Yes, it's because it sees the intermediate
> state (6,1) when it shouldn't (it processes
> each foreign key separ
--
[EMAIL PROTECTED]
Hi !
My system is i686/Linux Mandrake 7.0/Postgresql v-7.0.2.
I found a bug in the sql command ALTER TABLE ADD CONSTRAINT..., when I tried to add a
composite foreign key constraint
(a FK with more than one attribute). The problem is in the file identified by
$Header: /hom
Inheritance is one of the most useful and 'marketed' features in PostgreSQL.
However its behavior is not what one expected it to be. Inherited tables do
not inherit some constraints, including primary and foreing keys.
This information is very important, specially for newbies, who can get very
f
pgsql-bugs:
Hello!
I install postgres 7.1 on solaris 2.6(sparc cpu).And create some db,runing
normal.Today,I want to restart the database,it report "FATAL 1: configuration file
`postgresql.conf' has wrong permissions",I check and change the permission to 775 ,but
fail either,can you help.
[EMAIL PROTECTED] (Lee Harr) writes:
> Is this a bug?
> create table foo( c char(2)
> check (c in ('09', '10', '11', '12', 'n/a'))
> );
I don't think so; at least, I don't think there's any way in the general
case for the system to realize that some part of a check condition can
never succ
Hi, i've posted various problems regarding inheritance in postgres,
Never see a reply :(
Well, beside the referential constraint issue ( that can be solved by
hand ), the most frustrating is that queries like
DELETE FROM table* where key = some_value
Fails ( parser error ). ( UPDATE either )
>> Well, beside the referential constraint issue ( that can be solved by
>> hand ), the most frustrating is that queries like
>> DELETE FROM table* where key = some_value
>> Fails ( parser error ). ( UPDATE either )
Not as of 7.1.
regards, tom lane
-
> > On Wed, 18 Jul 2001, Tom Lane wrote:
> >
> > > Reinhard Max <[EMAIL PROTECTED]> writes:
> > > > On Wed, 18 Jul 2001, Bruce Momjian wrote:
> > > >> Do you have any idea how this will work with earlier TCL versions?
> > >
> > > > It won't. If pgtcl is supposed to still be able to compile with o
On Wed, Jul 18, 2001 at 02:53:22PM -0400, Tom Lane wrote:
> > It won't. If pgtcl is supposed to still be able to compile with older
> > versions of Tcl, the changes have to be made a compile time option.
>
> Please do that and resubmit the patch. We really don't want to give up
> backwards com
On Sat, 30 Jun 2001 13:10:17 +0800, Zhan Yi <[EMAIL PROTECTED]> wrote:
> I found performance problem.
>
> createdbspeed fast
>
> after many inserts, updates then delete all from tables and redo the same
> thing
> speed degrade
>
> drop table and rebuild table red
bonolin <[EMAIL PROTECTED]> writes:
> I install postgres 7.1 on solaris 2.6(sparc cpu).And create some
> db,runing normal.Today,I want to restart the database,it report
> "FATAL 1: configuration file `postgresql.conf' has wrong
> permissions",I check and change the permission to 775 ,but f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Isn't the file in /data, which is 700. Why do we care what permissions
> we give it?
Indeed. I could understand having a postmaster-start-time check that
$PGDATA has mode 700 (initdb makes this true anyway, but having the
postmaster double-check is no
> bonolin <[EMAIL PROTECTED]> writes:
> > I install postgres 7.1 on solaris 2.6(sparc cpu).And create some
> > db,runing normal.Today,I want to restart the database,it report
> > "FATAL 1: configuration file `postgresql.conf' has wrong
> > permissions",I check and change the permission to
>
> Hi, i've posted various problems regarding inheritance in postgres,
> Never see a reply :(
>
> Well, beside the referential constraint issue ( that can be solved by
> hand ), the most frustrating is that queries like
>
> DELETE FROM table* where key = some_value
>
> Fails ( parser error )
Is this a bug?
create table foo( c char(2)
check (c in ('09', '10', '11', '12', 'n/a'))
);
CREATE
insert into foo values('09');
INSERT
insert into foo values('10');
INSERT
insert into foo values('08');
ExecAppend: rejected due to CHECK constraint foo_c
insert into foo values('n/a');
> On Wed, 18 Jul 2001, Tom Lane wrote:
>
> > Reinhard Max <[EMAIL PROTECTED]> writes:
> > > On Wed, 18 Jul 2001, Bruce Momjian wrote:
> > >> Do you have any idea how this will work with earlier TCL versions?
> >
> > > It won't. If pgtcl is supposed to still be able to compile with older
> > > ver
Reinhard Max writes:
> OK, I'll pack the new stuff inside #ifdef TCL_UTF8 and define that if
> the Tcl version is 8.1 or greater.
No, please add a configure check for Tcl_UtfToExternalDString or some
other function representative of this interface..
--
Peter Eisentraut [EMAIL PROTECTED] ht
> On Fri, 20 Jul 2001, Peter Eisentraut wrote:
>
> > Reinhard Max writes:
> >
> > > OK, I'll pack the new stuff inside #ifdef TCL_UTF8 and define that if
> > > the Tcl version is 8.1 or greater.
> >
> > No, please add a configure check for Tcl_UtfToExternalDString or
> > some other function repre
On Fri, 20 Jul 2001, Peter Eisentraut wrote:
> Reinhard Max writes:
>
> > OK, I'll pack the new stuff inside #ifdef TCL_UTF8 and define that if
> > the Tcl version is 8.1 or greater.
>
> No, please add a configure check for Tcl_UtfToExternalDString or
> some other function representative of this
>
> Is this a bug?
>
> create table foo( c char(2)
> check (c in ('09', '10', '11', '12', 'n/a'))
> );
> CREATE
>
> insert into foo values('09');
> INSERT
>
> insert into foo values('10');
> INSERT
>
> insert into foo values('08');
> ExecAppend: rejected due to CHECK constraint foo_c
>
20 matches
Mail list logo
