[GENERAL] cache lookup failed
After create function and trigger, when I update "fams" by delete entry in table "indi" I get this message : ERROR: fmgr_info: function 19968: cache lookup failed Here is an SQL script that makes this happen: -- create table indi( id serial primary key, first_name varchar(40), last_name varchar(40), surname varchar(40), sex char check (sex='M' or sex='F' or sex=''), refn varchar(40) unique check (first_name notnull or last_name notnull or surname notnull); create table fams ( id serial primary key, husb int check (sex(husb)='M' or sex(husb)=''), wife int check (sex(wife)='F' or sex(wife)=''), refn varchar(40) unique, foreign key (husb) references indi on delete set null on update cascade, foreign key (wife) references indi on delete set null on update cascade, check (husb wife)); create function sex(int) returns char as 'select sex from indi where id = $1;' language 'sql'; create function func_fams() returns opaque as ' delete from fams where (husb isnull and wife isnull);' language 'plpgsql'; create trigger trig_fams after update on fams for each row execute procedure func_fams(); pollet-lorand= select * from indi; id | first_name | last_name | surname | sex | refn ++---+-+-+-- 4 | Jacqueline Anna Marie-Ange | LORAND| | | 1 | Fabrice| POLLET| | M | 3 | Véronique | LEROY | | F | 9 | Maurice Joseph | POLLET| | | (4 rows) pollet-lorand= select * from fams; id | husb | wife | refn +--+--+-- 1 |1 |3 | 4 |9 | | (2 rows) pollet-lorand= delete from indi where id=9; ERROR: fmgr_info: function 19968: cache lookup failed -- Fabrice POLLET ENSTA / LEI / AMI 32 boulevard VictorTél: +33 01 45 52 54 25 75739 PARIS CEDEX 15Fax: +33 01 45 52 55 87 F R A N C E
Re: [GENERAL] Re: [HACKERS] My new job
On Sat, 14 Oct 2000, Philip Warner wrote: The fear is that this may distort other priorities - hence why increased transparency in decision making is important. If Bruce, Tom Jan make a design decision, then chances are it's going to be pretty good. The problem is it will/may be seen as a GB decision. I don't know ... the recent discussion in -hackers on the whole ALTER TABLE DROP COLUMN tends to show that even those "in the pay of" don't necessarily agree :)
Re: [GENERAL] Re: [HACKERS] My new job
"Ross J. Reedstrom" [EMAIL PROTECTED] writes: So, I am really saying that core doesn't do much. You non-core folks aren't missing anything. Yeah, that's what you say in public ... There is no cabal! It's true that very little goes on on the private core mailing list, and we try to keep it that way. I think that most of the power that core has (such as it is) is that people on pghackers are willing to defer to us on decisions like what the release schedule should be. There are a dozen or more non-core people with CVS write access, so it's not like core is tightly controlling what happens to the code. I think ideally our role is one of cat herders, as you put it --- making the kinds of decisions that a group of dozens or hundreds can't make effectively. But the long-term direction of the project is largely determined by what the individual CVS committers choose to work on. In that sense, a core member has no more power than any non-core committer. (Case in point: Peter E. has had more influence on what 7.1 will look like than most of core ;-).) When you look at it from that point of view, power comes from having time to work on the code. In that sense, now that Great Bridge is paying me to work full-time on Postgres, I personally may be the most dangerous loose cannon on the deck. (Jan is less dangerous right at the moment only because he's distracted by moving concerns. Once he's settled again in Norfolk, look out...) Outer joins will be in 7.1 because *I* decided that would be a good thing to work on --- this wasn't a core decision, nor one imposed on me by Great Bridge. I doubt anyone will complain too hard about that particular choice, but further down the road I might make more debatable choices about how to spend my time. I agree 100% with your comments that openness of decision-making is a critical element in keeping the trust of the community. But looking at it as just an issue of core vs non-core is missing some part of the problem. Everyone who contributes code has a responsibility, proportionate to how much work they're doing, to ensure that the rest of the community understands and approves of what they're doing. regards, tom lane
Re: [GENERAL] Re: [HACKERS] My new job
At 22:12 13/10/00 -0400, Bruce Momjian wrote: The majority of core discussions are closed because either we need to decide on a central direction for the project (release date) These are the things that you should consider making more transparent. or we need to discuss something that would embarrass someone if it were publically known. Personal opinions are of course private. Can you think of an example of a secret embarrassing item that has affected the direction of the project? I'd be fascinated! You know, we have to take people aside once and a while and get them back on course. Of course, we do that for core members too. In fact, we built a shed outside especially for Jan, who is in Poland giving a speech and can't possibly respond in a timely manner. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [GENERAL] Re: [HACKERS] My new job
On Sat, 14 Oct 2000, Philip Warner wrote: The fear is that this may distort other priorities - hence why increased transparency in decision making is important. If Bruce, Tom Jan make a design decision, then chances are it's going to be pretty good. The problem is it will/may be seen as a GB decision. I don't know ... the recent discussion in -hackers on the whole ALTER TABLE DROP COLUMN tends to show that even those "in the pay of" don't necessarily agree :) Man, Tom, our cover is working perfectly. Let's disagree on something again. That will really convince them. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [GENERAL] Re: [HACKERS] My new job
I think ideally our role is one of cat herders, as you put it --- making the kinds of decisions that a group of dozens or hundreds can't make effectively. But the long-term direction of the project is largely determined by what the individual CVS committers choose to work on. In that sense, a core member has no more power than any non-core committer. (Case in point: Peter E. has had more influence on what 7.1 will look like than most of core ;-).) Jan says that if I start coding more, GB will have to hire more developers to clean up after me. Now, is that supposed to make me feel valued? :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[GENERAL] Matlab Mex Interface
We have recently developed an interface to PostgreSQL for Matlab. The interface is implemented as 'C' mex wrappers around libpq. Most of the database connection and query execution functions are implemented, and it supports default (text) and binary transfers directly into Matlab variables (including text, integer, and floating point arrays). The functions have been tested on Linux, SGI 32 bit, and Windows architectures. Other architectures should be trivial to support - just a matter of compiling. We would like to make this interface freely available, and would like to know how much interest there would be in the interface. Also, would it be worthwhile to package and make available with PostgreSQL. Any comments? Darrin Rothe Arizona State University [EMAIL PROTECTED]
Re: [GENERAL] Matlab Mex Interface
On Fri, 13 Oct 2000, Darrin Rothe wrote: We have recently developed an interface to PostgreSQL for Matlab. The interface is implemented as 'C' mex wrappers around libpq. Most of the database connection and query execution functions are implemented, and it supports default (text) and binary transfers directly into Matlab variables (including text, integer, and floating point arrays). The functions have been tested on Linux, SGI 32 bit, and Windows architectures. Other architectures should be trivial to support - just a matter of compiling. We would like to make this interface freely available, and would like to know how much interest there would be in the interface. Also, would it be worthwhile to package and make available with PostgreSQL. the only problem that I could see with this is the license that it is under ... if under BSD license, we could easily extend configure to have a --with-matlab option ...
Re: [GENERAL] Question about pg_dump
"Mitch Vincent" [EMAIL PROTECTED] writes: Well, all you're doing with pg_dump is getting a snapshot of the database at a single point in time -- as pg_dump reads the data out of the tables, I'm sure that it won't go back and re-read tables that have changed since it was first started. On the other hand, if pg_dump is busy on table A and table Z changes, even though it's after the pg_dump process starts, I would assume the changes to table Z would get dumped. I'm assuming a lot -- all of that is based on the fact that I've never seen pg_dump lock the whole database down (though I do think it locks the table it's dumping while it's dumping it).. Under MVCC, pg_dump doesn't lock much of anything --- ordinary read and write transactions can proceed with abandon. You would see some interlocking behavior with schema-altering commands (eg, ALTER or DROP TABLE) but not with updates of user data. The general rule for SELECT-only transactions, which is what a pg_dump run is, is that the transaction sees all and only that data written by transactions that committed before it started. I've just finished putting together a talk about MVCC transaction processing --- both how it behaves and how it's implemented --- for the upcoming OSDN database conference. I think the slides for that talk are fairly self-contained and might be of general interest; shall I brace Vince about putting them up on the website? regards, tom lane
Re: [GENERAL] Question about pg_dump
On Sat, 14 Oct 2000, Tom Lane wrote: I've just finished putting together a talk about MVCC transaction processing --- both how it behaves and how it's implemented --- for the upcoming OSDN database conference. I think the slides for that talk are fairly self-contained and might be of general interest; shall I brace Vince about putting them up on the website? I would certainly be interested in them, FWIW... -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Re: [GENERAL] Not null contraints
"Tamsin" [EMAIL PROTECTED] writes: I want to remove a not null constraint from a table. I've read the posts about having to rename, recreate without not nulls insert back into the table. This is fine, but the table also has a lot of foreign keys/rules etc recreating all these is a bit of pain. I tried updating pg_attribute setting attnotnull to 'f' for the field in question. This seems to have worked. Is it safe?! - is there anything else I should be aware of? Yup, that should do the trick. Not much magic here... regards, tom lane
RE: [GENERAL] Matlab Mex Interface
On Fri, 13 Oct 2000, Darrin Rothe wrote:
Licensing shouldn't be an issue. I have permission from the university to
release it into "the public domain." However, I intend to attach the BSD
style license/disclaimer which exists with PostgreSQL. Matlab's license
does not impose any restrictions on programs written using their API.
However, to compile the routines, one would need Matlab installed in order
to pick up some of their header files.
that's okay ... PyGreSQL needs Python, Perl needs perl, etc
... requirements won't limit its ability to be included, only licensing :)
Darrin Rothe
[EMAIL PROTECTED]
-Original Message-
From: The Hermit Hacker [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 13, 2000 8:58 PM
To: Darrin Rothe
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Matlab Mex Interface
On Fri, 13 Oct 2000, Darrin Rothe wrote:
We have recently developed an interface to PostgreSQL for Matlab.
The interface is implemented as 'C' mex wrappers around libpq.
Most of the
database connection and query execution functions are
implemented, and it
supports default (text) and binary transfers directly into
Matlab variables
(including text, integer, and floating point arrays).
The functions have been tested on Linux, SGI 32 bit, and Windows
architectures. Other architectures should be trivial to
support - just a
matter of compiling.
We would like to make this interface freely available, and would like to
know how much interest there would be in the interface. Also,
would it be
worthwhile to package and make available with PostgreSQL.
the only problem that I could see with this is the license that it is
under ... if under BSD license, we could easily extend configure to have a
--with-matlab option ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [GENERAL] config
Michael Engelhart [EMAIL PROTECTED] writes:
Thanks Adam. Yeah, I know that it uses a mach kernel and variant of
freebsd runs atop the kernel. I would attempt the FreeBSD template
but the other snag is that it has to compile on PowerPC.
FreeBSD template seems like it'd be a good starting point. 7.0.*
will probably not work on PPC unless you compile with optimization
level -O0, so tweak CFLAGS in the template that way before running
configure. Otherwise it seems like it'd more or less work --- give
it a shot and let us know how it goes.
BTW, I think the PPC optimization issues are solved in current sources.
From a development perspective it'd be more interesting to hear your
report on what happens with a current nightly snapshot instead of 7.0.2.
regards, tom "didn't order my OS X yet :-(" lane
Re: [GENERAL] Not null contraints
At 00:26 14/10/00 -0400, Tom Lane wrote: I tried updating pg_attribute setting attnotnull to 'f' for the field in question. This seems to have worked. Is it safe?! - is there anything else I should be aware of? Yup, that should do the trick. Not much magic here... Just to confirm - does this mean we have ALTER TABLE ADD CONSTRAINT, but not ALTER TABLE DROP CONSTRAINT. If so, should it go on a list somewhere? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [GENERAL] Matlab Mex Interface
"Darrin Rothe" [EMAIL PROTECTED] writes: We have recently developed an interface to PostgreSQL for Matlab. ... We would like to make this interface freely available, and would like to know how much interest there would be in the interface. Also, would it be worthwhile to package and make available with PostgreSQL. Sounds pretty cool to me! As for distribution, you could either stick it up on a website of your own, or submit it for inclusion in the Postgres distribution. There are two possible levels of inclusion in the distro: as a contrib package or as a main-tree interface subdirectory. The difference is that contrib packages are never built by default, and so armed core members are not going to show up on your doorstep if the thing doesn't build on some random platform ;-). If you want to go for main-tree status, you had better be prepared to answer the bell when there's a problem. A possible compromise is contrib now with hopes of being integrated into the main tree after a shakedown period. Also, we'd really like straight BSD license for anything included in the distribution, whereas if you distribute it separately you can use GPL or whatever you like. This project seems worthwhile enough to me that you should let it out on some terms. Your choice what license terms to use and how much support commitment you want to make. Let us know. regards, tom lane
Re: [GENERAL] config
Thanks to everyone for giving me a starting point.
here's what I tried so far:
changed the CFLAGS in the src/template/freebsd file to:
CFLAGS='-O0 -pipe'
did
./configure --with-template=freebsd
configure succeeded.
Did a make and started to build. During the build, there were a ton of messages of
this type:
../../../../src/include/catalog/pg_type.h:414: stray '\' in program
make exited with this:
cc -c -I../../../src/include -O0 -pipe -Wall -Wmissing-prototypes
-Wmissing-declarations -o dynloader.o dynloader.c
dynloader.c:42: header file 'link.h' not found
dynloader.c:43: header file 'dlfcn.h' not found
../../../src/include/dynloader.h:19: header file 'link.h' not found
make[3]: *** [dynloader.o] Error 1
make[2]: *** [port-recursive] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
Not sure if configure didn't move the correct files or if there was something else
wrong. I was using the lastest developer snapshot for testing. I also tried it on a
stock 7.0.2 source but got the same error.
Any ideas? I'm willing to try and get this working but unfortunately my grasp of the
process is pretty weak.
Mike
On Friday, October 13, 2000, at 11:42 PM, Tom Lane wrote:
Michael Engelhart [EMAIL PROTECTED] writes:
Thanks Adam. Yeah, I know that it uses a mach kernel and variant of
freebsd runs atop the kernel. I would attempt the FreeBSD template
but the other snag is that it has to compile on PowerPC.
FreeBSD template seems like it'd be a good starting point. 7.0.*
will probably not work on PPC unless you compile with optimization
level -O0, so tweak CFLAGS in the template that way before running
configure. Otherwise it seems like it'd more or less work --- give
it a shot and let us know how it goes.
BTW, I think the PPC optimization issues are solved in current sources.
From a development perspective it'd be more interesting to hear your
report on what happens with a current nightly snapshot instead of 7.0.2.
regards, tom "didn't order my OS X yet :-(" lane
Re: [GENERAL] Not null contraints
Philip Warner [EMAIL PROTECTED] writes: At 00:26 14/10/00 -0400, Tom Lane wrote: I tried updating pg_attribute setting attnotnull to 'f' for the field in question. This seems to have worked. Is it safe?! - is there anything else I should be aware of? Yup, that should do the trick. Not much magic here... Just to confirm - does this mean we have ALTER TABLE ADD CONSTRAINT, but not ALTER TABLE DROP CONSTRAINT. If so, should it go on a list somewhere? No, it just means that NOT NULL constraint is handled via a special flag attached to the column's pg_attribute entry. More general constraints are handled with other catalog entries. (I think this is largely a historical artifact, not necessarily a good idea.) Another relevant comment is that *removing* a NOT NULL constraint doesn't pose any risk of creating invalid entries in the table data. So there's no need to worry about cross-checking. regards, tom lane
