Re: [HACKERS] PGSQL problem with weblogic and OID data type
Sanath Peiris wrote: > > Hi everybody, > > I gotta this problem while I was trying to work with weblogic and postgresql with >storing images as byte arrays. > > First, I used JBOSS-2.2.2 as an application server and Postgresql-7.0.3 as a >database serevr to run one of my Java enterprise applications. There I used "OID" >data type to store images, and worked fine with the above combination. I used >jdbc7.0-1.2.jar as a postgresql jdbc driver. > > Please look at the sample codes given below. > > InputStream banner; > String bannerID = "some id'; > PreparedStatement pstmt = > dbConnection.prepareStatement(?Insert into tablename (BannerID, >Banner) values(?,?)?); > int NoOfBytes = banner.available(); > byte[] bytebuffer = new byte[NoOfBytes]; > banner.read(bytebuffer); > pstmt.setString(1, bannerID); > pstmt.setBytes(2, bytebuffer); > int resultCount = pstmt.executeUpdate(); > > After this, I successfully deployed this application in weblogic-6.0 using the same >Postgresql database and the jdbc driver. There, some other database accessing parts >worked fine, but the above image thing is not worked and gave an error message like >"FastPath call returned ERROR: lo_write: invalid large obj descriptor (0)". > > I think nothing wrong with the codes...and can be a driver problem with >weblogic..Can anybody explain the above pls. Sanath Dont know if anybody replied to your question yet. But you should set your AutoCommit to false e.a conn.setAutoCommit(false); Do this before you execute your preparedstatement. That should fix your problem. Regards Phillip ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Odd error...
At 22:12 16/07/01 -0500, Dominic J. Eidson wrote: >morannon:~>pg_dump -t bboard openacs | less >getTables(): SELECT (for VIEW ec_subsubcategories_augmented) returned NULL oid >SELECT was: SELECT definition as viewdef, (select oid from pg_rewrite >where rulename='_RET' || viewname) as view_oid from pg_views where >viewname = 'ec_subsubcategories_augmented'; > >Any ideas what would cause this? Probably the length of the view name; which version are you running? I haven't look at PG for a while, but I thought this was fixed in 7.1.2 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 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Odd error...
morannon:~>pg_dump -t bboard openacs | less getTables(): SELECT (for VIEW ec_subsubcategories_augmented) returned NULL oid SELECT was: SELECT definition as viewdef, (select oid from pg_rewrite where rulename='_RET' || viewname) as view_oid from pg_views where viewname = 'ec_subsubcategories_augmented'; Any ideas what would cause this? -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_depend
Christopher Kings-Lynne wrote: > > > Whether the default DROP behavior should be CASCADE, RESTRICT, or the > > current laissez-faire behavior remains to be debated ;-). The spec > > is no help since it has no default: DROP *requires* a CASCADE or > > RESTRICT option in SQL92. But I doubt our users will let us get away > > with changing the syntax that way. So, once we have the CASCADE and > > RESTRICT options implemented, we'll need to decide what an unadorned > > DROP should do. Opinions anyone? > > Hmmm...an unadorned drop could remove the object without RESRICTing it or > CASCADEing it. Hence, if there are objects that depend on it, the object > will be removed anyway, and dependent objects will not be touched. We could mark the objects(and their dependent objects) as *INVALID*. They would revive when reference objects revive in the world of *name*s. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: SOMAXCONN (was Re: Solaris source code)
[EMAIL PROTECTED] (Nathan Myers) writes: > Considering the Apache comment about some systems truncating instead > of limiting... 1&0xff is 16. Maybe 10239 would be a better choice, > or 16383. Hmm. If the Apache comment is real, then that would not help on those systems. Remember that the actual listen request is going to be 2*MaxBackends in practically all cases. The only thing that would save you from getting an unexpectedly small backlog parameter in such a case is to set PG_SOMAXCONN to 255. Perhaps we should just do that and not worry about whether the Apache info is accurate or not. But I'd kind of like to see chapter and verse, ie, at least one specific system that demonstrably fails to perform the clamp-to-255 for itself, before we lobotomize the code that way. ISTM a conformant implementation of listen() would limit the given value to 255 before storing it into an 8-bit field, not just lose high order bits. > After doing some more reading, I find that most OSes do not reject > connect requests that would exceed the specified backlog; instead, > they ignore the connection request and assume the client will retry > later. Therefore, it appears cannot use a small backlog to shed load > unless we assume that clients will time out quickly by themselves. Hm. newgate is a machine on my local net that's not currently up. $ time psql -h newgate postgres psql: could not connect to server: Connection timed out Is the server running on host newgate and accepting TCP/IP connections on port 5432? real1m13.33s user0m0.02s sys 0m0.01s $ That's on HPUX 10.20. On an old Linux distro, the same timeout seems to be about 21 seconds, which is still pretty long by some standards. Do the TCP specs recommend anything particular about no-response-to-SYN timeouts? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
> *ALTER TABLE* isn't as easy as *CREATE TABLE*. > It has another problem because it hasn't implemented > *DEFAULT* yet. Just out of interest, is there a special reason it's difficult to implement the DEFAULT feature of alter table add column? Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
Christopher Kings-Lynne wrote: > > > *ALTER TABLE* isn't as easy as *CREATE TABLE*. > > It has another problem because it hasn't implemented > > *DEFAULT* yet. > > Just out of interest, is there a special reason it's difficult to implement > the DEFAULT feature of alter table add column? > Without *DEFAULT* we don't have to touch the table file at all. With *DEFAULT* we have to fill the new column with the *DEFAULT* value for all existent rows. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: [HACKERS] pg_depend
> Whether the default DROP behavior should be CASCADE, RESTRICT, or the > current laissez-faire behavior remains to be debated ;-). The spec > is no help since it has no default: DROP *requires* a CASCADE or > RESTRICT option in SQL92. But I doubt our users will let us get away > with changing the syntax that way. So, once we have the CASCADE and > RESTRICT options implemented, we'll need to decide what an unadorned > DROP should do. Opinions anyone? Hmmm...an unadorned drop could remove the object without RESRICTing it or CASCADEing it. Hence, if there are objects that depend on it, the object will be removed anyway, and dependent objects will not be touched. It's one of those things that gives the DBA power, but might let them munge their database. (Although it's exactly the same as the current way things happen) Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_depend
> Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Is it really determined that *DROP OBJECT* drops the objects > > which are dependent on it ? > > DROP object CASCADE should work that way, because that's what the spec > says. > > Whether the default DROP behavior should be CASCADE, RESTRICT, or the > current laissez-faire behavior remains to be debated ;-). The spec > is no help since it has no default: DROP *requires* a CASCADE or > RESTRICT option in SQL92. But I doubt our users will let us get away > with changing the syntax that way. So, once we have the CASCADE and > RESTRICT options implemented, we'll need to decide what an unadorned > DROP should do. Opinions anyone? Don't forget RENAME. And what do we do if two items depend on the same object. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_depend
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Is it really determined that *DROP OBJECT* drops the objects > which are dependent on it ? DROP object CASCADE should work that way, because that's what the spec says. Whether the default DROP behavior should be CASCADE, RESTRICT, or the current laissez-faire behavior remains to be debated ;-). The spec is no help since it has no default: DROP *requires* a CASCADE or RESTRICT option in SQL92. But I doubt our users will let us get away with changing the syntax that way. So, once we have the CASCADE and RESTRICT options implemented, we'll need to decide what an unadorned DROP should do. Opinions anyone? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_depend
On Tue, 17 Jul 2001, Hiroshi Inoue wrote: > Peter Eisentraut wrote: > > > > Alex Pilosov writes: > > > > > drop object [RESTRICT | CASCADE] > > > > > > to make use of dependency info. > > > > That was me. The point, however, was, given object id 145928, how the > > heck to you know what table this comes from? > > > > Is it really determined that *DROP OBJECT* drops the objects > which are dependent on it ? If you used DROP OBJECT CASCADE, yes. That's what CASCADE is saying. I think the idea is that you can say what happens - delete dependents, or do something else. Take care, Bill ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_depend
Peter Eisentraut wrote: > > Alex Pilosov writes: > > > > I'm not so convinced on that idea. Assume you're dropping object foo. > > > You look at pg_depend and see that objects 145928, 264792, and 1893723 > > > depend on it. Great, what do you do now? > > I believe someone else previously suggested this: > > > > drop object [RESTRICT | CASCADE] > > > > to make use of dependency info. > > That was me. The point, however, was, given object id 145928, how the > heck to you know what table this comes from? > Is it really determined that *DROP OBJECT* drops the objects which are dependent on it ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
Tom Lane wrote: > > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > Running: > > ALTER TABLE table ADD COLUMN column SERIAL; > > Defines a column as int4 but does not create the sequence or attempt > > to set the default value. > > Yeah ... SERIAL is implemented as a hack in the parsing of CREATE > TABLE, but there's no corresponding hack in ALTER TABLE. A bug, > no doubt about it, but I don't much like the obvious fix of duplicating > the hack in two places. Isn't there a cleaner way to deal with this > "data type"? > *ALTER TABLE* isn't as easy as *CREATE TABLE*. It has another problem because it hasn't implemented *DEFAULT* yet. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_depend
Peter Eisentraut <[EMAIL PROTECTED]> writes: > You look at pg_depend and see that objects 145928, 264792, and 1893723 > depend on it. Great, what do you do now? >> I believe someone else previously suggested this: >> drop object [RESTRICT | CASCADE] >> to make use of dependency info. > That was me. The point, however, was, given object id 145928, how the > heck to you know what table this comes from? Even more to the point, what guarantee can we have that that OID even defines a unique object at all? We have unique indexes that ensure there are not two tables with the same OID, or two functions with the same OID, etc --- but none that ensure uniqueness across system catalogs. The objects would need to be identified by two-part IDs, one part specifying the object type and one giving its OID (which is known unique within that type). Possibly object type would be best handled by giving the OID of the system catalog containing the object's definition row. In any case, looking at the type part would let users of the pg_depend catalog figure out what they needed to do. BTW, pg_description is broken because it assumes that OID alone is a sufficient identifier ... but since it's such a noncritical function, I haven't gotten too excited about it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_depend
> Alex Pilosov writes: > > > > I'm not so convinced on that idea. Assume you're dropping object foo. > > > You look at pg_depend and see that objects 145928, 264792, and 1893723 > > > depend on it. Great, what do you do now? > > I believe someone else previously suggested this: > > > > drop object [RESTRICT | CASCADE] > > > > to make use of dependency info. > > That was me. The point, however, was, given object id 145928, how the > heck to you know what table this comes from? I think we will need the relid of the system table. I imagine four columns: object relid object oid reference relid references oid -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_depend
Let me clearify. I am suggesting system table relid for each entry: > object sysrelid > object oid > reference sysrelid > references oid -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_depend
> The objects would need to be identified by two-part IDs, one part > specifying the object type and one giving its OID (which is known unique > within that type). Possibly object type would be best handled by giving > the OID of the system catalog containing the object's definition row. > In any case, looking at the type part would let users of the pg_depend > catalog figure out what they needed to do. Yes, exactly. Also, I can see code that will handles dependencies differently if it is a pg_class or pg_type row that is mentioned in pg_depend. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_depend
On Tue, 17 Jul 2001, Peter Eisentraut wrote: > Alex Pilosov writes: > > > > I'm not so convinced on that idea. Assume you're dropping object foo. > > > You look at pg_depend and see that objects 145928, 264792, and 1893723 > > > depend on it. Great, what do you do now? > > I believe someone else previously suggested this: > > > > drop object [RESTRICT | CASCADE] > > > > to make use of dependency info. > > That was me. The point, however, was, given object id 145928, how the > heck to you know what table this comes from? You have three columns, depender, dependee, and the third the oid of the entry of pg_class describing what the depender is. Oh, actually you'd probably need four columns, depender, dependee, depender in pg_class, and dependee in pg_class. Take care, Bill ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_depend
On Mon, 16 Jul 2001, Peter Eisentraut wrote: > Bruce Momjian writes: > > > I have found that many TODO items would benefit from a pg_depend table > > that tracks object dependencies. TODO updated. > > I'm not so convinced on that idea. Assume you're dropping object foo. > You look at pg_depend and see that objects 145928, 264792, and 1893723 > depend on it. Great, what do you do now? I believe someone else previously suggested this: drop object [RESTRICT | CASCADE] to make use of dependency info. > Every system catalog (except the really badly designed ones) already > contains dependency information. What might help is that we make the > internal API for altering and dropping any kind of object more consistent > and general so that they can call each other in the dependency case. > (E.g., make sure none of them require whereToSendOutput or parser state as > an argument.) Yes, that's definitely requirement to implement the above... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_depend
On Tue, 17 Jul 2001, Peter Eisentraut wrote: > Alex Pilosov writes: > > > > I'm not so convinced on that idea. Assume you're dropping object foo. > > > You look at pg_depend and see that objects 145928, 264792, and 1893723 > > > depend on it. Great, what do you do now? > > I believe someone else previously suggested this: > > > > drop object [RESTRICT | CASCADE] > > > > to make use of dependency info. > > That was me. The point, however, was, given object id 145928, how the > heck to you know what table this comes from? have a view pg_objecttype which is a UNION across all the [relevant] system tables sounds fine to me, but maybe I'm missing something? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_depend
Alex Pilosov writes: > > I'm not so convinced on that idea. Assume you're dropping object foo. > > You look at pg_depend and see that objects 145928, 264792, and 1893723 > > depend on it. Great, what do you do now? > I believe someone else previously suggested this: > > drop object [RESTRICT | CASCADE] > > to make use of dependency info. That was me. The point, however, was, given object id 145928, how the heck to you know what table this comes from? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] NetBSD 1.5.1(HP300)
Larry Rosenman writes:
> When it trys to run the following:
> configure:7174: gcc -o conftest -O2 -pipe -L/usr/local/lib conftest.c
> -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit 1>&5
> configure: failed program was:
> #line 7170 "configure"
> #include "confdefs.h"
> int main() { return 0; }
> $
>
> that program dies:
> $ cat conftest.c
> #include "confdefs.h"
> int main() { return 0; }
>
> $ /lib conftest.c -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
> <
> $ ./conftest
> /usr/libexec/ld.so: Undefined symbol "_tputs" in
> conftest:/usr/lib/libedit.so.2.3
Yes, I've seen that before. The program links okay but does not execute
because of an undefined symbol. I think that's a linker bug. Why would I
need a linker if it doesn't make sure the executable has fully resolved
symbols? This can be observed at least with NetBSD -ledit and OpenBSD
-lreadline.
Here's how I would expect it to work:
configure:3249: checking for readline
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline 1>&5
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libreadline.so: undefined reference
to `tgetnum'
[snip]
collect2: ld returned 1 exit status
configure: failed program was:
#line 3260 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char readline();
int main() {
readline()
; return 0; }
[snip]
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline -ltermcap 1>&5
[success]
Can you take this to the OS developers?
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
> "Rod Taylor" <[EMAIL PROTECTED]> writes: > > Running: > > ALTER TABLE table ADD COLUMN column SERIAL; > > Defines a column as int4 but does not create the sequence or attempt > > to set the default value. > > Yeah ... SERIAL is implemented as a hack in the parsing of CREATE > TABLE, but there's no corresponding hack in ALTER TABLE. A bug, > no doubt about it, but I don't much like the obvious fix of duplicating > the hack in two places. Isn't there a cleaner way to deal with this > "data type"? Added to TODO. -- 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_depend
> Bruce Momjian writes: > > > I have found that many TODO items would benefit from a pg_depend table > > that tracks object dependencies. TODO updated. > > I'm not so convinced on that idea. Assume you're dropping object foo. > You look at pg_depend and see that objects 145928, 264792, and 1893723 > depend on it. Great, what do you do now? > > Every system catalog (except the really badly designed ones) already > contains dependency information. What might help is that we make the > internal API for altering and dropping any kind of object more consistent > and general so that they can call each other in the dependency case. > (E.g., make sure none of them require whereToSendOutput or parser state as > an argument.) Yes, it is not simple. The table is just one part of it. Code has to do lookups and have cascade/failure options based on what it finds. Things can get quite complicated, especially circular dependencies. It needs a general overhaul and has to hit every area. We need a central location to keep all this info. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: SOMAXCONN (was Re: Solaris source code)
On Sat, Jul 14, 2001 at 11:38:51AM -0400, Tom Lane wrote: > > The state of affairs in current sources is that the listen queue > parameter is MIN(MaxBackends * 2, PG_SOMAXCONN), where PG_SOMAXCONN > is a constant defined in config.h --- it's 1, hence a non-factor, > by default, but could be reduced if you have a kernel that doesn't > cope well with large listen-queue requests. We probably won't know > if there are any such systems until we get some field experience with > the new code, but we could have "configure" select a platform-dependent > value if we find such problems. Considering the Apache comment about some systems truncating instead of limiting... 1&0xff is 16. Maybe 10239 would be a better choice, or 16383. > So, having thought that through, I'm still of the opinion that holding > off accept is of little or no benefit to us. But it's not as simple > as it looks at first glance. Anyone have a different take on what the > behavior is likely to be? After doing some more reading, I find that most OSes do not reject connect requests that would exceed the specified backlog; instead, they ignore the connection request and assume the client will retry later. Therefore, it appears cannot use a small backlog to shed load unless we assume that clients will time out quickly by themselves. OTOH, maybe it's reasonable to assume that clients will time out, and that in the normal case authentication happens quickly. Then we can use a small listen() backlog, and never accept() if we have more than MaxBackend back ends. The OS will keep a small queue corresponding to our small backlog, and the clients will do our load shedding for us. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] NetBSD 1.5.1(HP300)
Reported to NetBSD as pr BIN/13486
LER
>> Original Message <<
On 7/16/01, 3:40:31 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
Re: [HACKERS] NetBSD 1.5.1(HP300):
> Larry Rosenman writes:
> > When it trys to run the following:
> > configure:7174: gcc -o conftest -O2 -pipe -L/usr/local/lib conftest.c
> > -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit 1>&5
> > configure: failed program was:
> > #line 7170 "configure"
> > #include "confdefs.h"
> > int main() { return 0; }
> > $
> >
> > that program dies:
> > $ cat conftest.c
> > #include "confdefs.h"
> > int main() { return 0; }
> >
> > $ /lib conftest.c -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
> > <
> > $ ./conftest
> > /usr/libexec/ld.so: Undefined symbol "_tputs" in
> > conftest:/usr/lib/libedit.so.2.3
> Yes, I've seen that before. The program links okay but does not execute
> because of an undefined symbol. I think that's a linker bug. Why would
I
> need a linker if it doesn't make sure the executable has fully resolved
> symbols? This can be observed at least with NetBSD -ledit and OpenBSD
> -lreadline.
> Here's how I would expect it to work:
> configure:3249: checking for readline
> configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline 1>&5
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libreadline.so:
undefined reference to `tgetnum'
> [snip]
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 3260 "configure"
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error. */
> /* We use char because int might match the return type of a gcc2
> builtin and then its argument prototype would still apply. */
> char readline();
> int main() {
> readline()
> ; return 0; }
> [snip]
> configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline
-ltermcap 1>&5
> [success]
> Can you take this to the OS developers?
> --
> Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] PostgreSQL : First impressions
Hi, I'm not sure if this is the right address to pass comments to PostGreSQL team, but here goes. I'm new to PostgreSQL and so far it looks quite interesting as an open source DBMS. There are a few quirks (i.e. can't alter field data types? Can't drop fields? ,etc), but I suppose I can live with them . Been using it for some web-based development and I must say I am pleasantly surprised to see how well it works for the last few weeks. Keep it up and cheers. Regards, John Huong P.S: Looking forward to the replication features in the to-do list ;). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] NetBSD 1.5.1(HP300)
Larry Rosenman writes: > in testing CVS tip(sort of), I found that you need -lcurses with > -ledit on NetBSD 1.5.1. > > _tputs in undefined otherwise. This is a known problem, but it hasn't been satisfactorily explained so far. The configure test links a program against -ledit and it seems to succeed without -lcurses. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
"Rod Taylor" <[EMAIL PROTECTED]> writes: > Running: > ALTER TABLE table ADD COLUMN column SERIAL; > Defines a column as int4 but does not create the sequence or attempt > to set the default value. Yeah ... SERIAL is implemented as a hack in the parsing of CREATE TABLE, but there's no corresponding hack in ALTER TABLE. A bug, no doubt about it, but I don't much like the obvious fix of duplicating the hack in two places. Isn't there a cleaner way to deal with this "data type"? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] NetBSD 1.5.1(HP300)
When it trys to run the following:
configure:7174: gcc -o conftest -O2 -pipe -L/usr/local/lib conftest.c
-lz -lcrypt -lresolv -lcompat -lm -lutil -ledit 1>&5
configure: failed program was:
#line 7170 "configure"
#include "confdefs.h"
int main() { return 0; }
$
that program dies:
$ cat conftest.c
#include "confdefs.h"
int main() { return 0; }
$ /lib conftest.c -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
<
$ ./conftest
/usr/libexec/ld.so: Undefined symbol "_tputs" in
conftest:/usr/lib/libedit.so.2.3
$
I'm not sure WHY configure doesn't add -lcurses, but it needs to.
I can give you a shell account on this box (WARNING: it's slow, it's a 25
Mhz 68040) if you want.
LER
>> Original Message <<
On 7/16/01, 2:44:17 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
Re: [HACKERS] NetBSD 1.5.1(HP300):
> Larry Rosenman writes:
> > in testing CVS tip(sort of), I found that you need -lcurses with
> > -ledit on NetBSD 1.5.1.
> >
> > _tputs in undefined otherwise.
> This is a known problem, but it hasn't been satisfactorily explained so
> far. The configure test links a program against -ledit and it seems to
> succeed without -lcurses.
> --
> Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_depend
Bruce Momjian writes: > I have found that many TODO items would benefit from a pg_depend table > that tracks object dependencies. TODO updated. I'm not so convinced on that idea. Assume you're dropping object foo. You look at pg_depend and see that objects 145928, 264792, and 1893723 depend on it. Great, what do you do now? Every system catalog (except the really badly designed ones) already contains dependency information. What might help is that we make the internal API for altering and dropping any kind of object more consistent and general so that they can call each other in the dependency case. (E.g., make sure none of them require whereToSendOutput or parser state as an argument.) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] What I do with PostgreSQL
This might not be the correct list to send this to, but none of the other lists seemed appropriate. A friend of mine who uses postgres extensively at his job suggested I might send y'all a note outlining what we do with it here. In general, I am discouraged from providing specific data to non-employees about what we do. But Dan (the aforementioned friend) said that you guys would be interested in knowing what I am currently doing with postgres, so that you know that its up to the challenges we don¹t often get to put hardware and software to. I am working in the publications division of the American Chemical Society. We are in the process of taking all of our 30+ journals from the last 150 or so years and digitizing them. This process entails scanning over 2.5 million pages (though this is really only a rough estimate. It could be much higher) and digitizing them. Our output is in several formats. First, we have the input TIFF (from the scans), we have PDF's which we render using Adobe Capture, XML (which we pay a vendor for), and a proprietary format called DjVu which is kind of Well, its like metadata. Initially, we were using perl scripts and shell scripts to traverse the entire filesystem looking for files. This got rather difficult and was time consuming. My suggestion was to just use a database for keeping track of stuff. We have something like 27 different instances of oracle running here on 4 or 5 different machines. I don't know much about our oracle stuff. My solution was to just go download and install postgres. Our hardware is a cluster of 3 ultra 10's, a pair of 700-dvd jukeboxes (with burners), a 2.5tb SAN, 10 DAT tape readers, a pair of dvd-roms, and 2 200gb disk packs (one for each of our tape-reading suns -- the other one manages the DVD jukes). We also run capture on four dell poweredge servers running NT. We run the DjVu software on an additional 3 poweredge servers. That stuff is NT. The SAN is run on a cluster of 4 sun e 3500's. I am pumping about 200gb a week through the pg database, and our estimated database size is something like 4tb by the end of the year. We populate the database with perl scripts. The sun that runs the dvd jukes is also our database server. We have shell scripts that look over our data on the disk, and we use sun's NFS to keep disks between the suns and some funky Sun smb-esque software to keep disks mounted on the nt boxes. And that's just the "large" database. I have an additional database that I am using to store the textual data we receive in the form of "crystallography information files" (http://www.iucr.org/) which are roughly 6,000 lines long. I have 10,000 of them stored at the moment in the database, going back to about 1996. As you can tell, this database is going to get much bigger. At the moment it's living on an Ultra 2 in a 2gb partition. In some ways, I am amazed that postgres has stood up to the challenge. In others, however, I am not in the least surprised. Its a fantastic piece of software that requires almost no intervention on my part. I talked to one of our oracle dba's about it. He actually (im not kidding here) did not believe it could be a database if it did not require maintenance. I am very happy with postgres and I am glad to provide information about our setup if you'd like to know anything else. If you'd like to quote me on the environment if youre interested in putting something in a FAQ (i.e., "can postgres scale up to > tb scale?"), that¹s fine as well, but I would like to make sure that it doesn¹t point to ACS and is not too specific. Anyhow, thanks for your hard work guys/gals. alex ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PGSQL problem with weblogic and OID data type
Hi everybody, I gotta this problem while I was trying to work with weblogic and postgresql with storing images as byte arrays. First, I used JBOSS-2.2.2 as an application server and Postgresql-7.0.3 as a database serevr to run one of my Java enterprise applications. There I used "OID" data type to store images, and worked fine with the above combination. I used jdbc7.0-1.2.jar as a postgresql jdbc driver. Please look at the sample codes given below. InputStream banner; String bannerID = "some id'; PreparedStatement pstmt = dbConnection.prepareStatement(Insert into tablename (BannerID, Banner) values(?,?)); int NoOfBytes = banner.available(); byte[] bytebuffer = new byte[NoOfBytes]; banner.read(bytebuffer); pstmt.setString(1, bannerID); pstmt.setBytes(2, bytebuffer); int resultCount = pstmt.executeUpdate(); After this, I successfully deployed this application in weblogic-6.0 using the same Postgresql database and the jdbc driver. There, some other database accessing parts worked fine, but the above image thing is not worked and gave an error message like "FastPath call returned ERROR: lo_write: invalid large obj descriptor (0)". I think nothing wrong with the codes...and can be a driver problem with weblogic..Can anybody explain the above pls. Thankx, Peiris Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] OLD in Trigger
Hi, Can anyone confirm whether I can do something like the following in a PL/pgsql trigger ( on table tab_a ) SELECT INTO tab_b * FROM OLD; or do I have to do - INSERT INTO tab_b SELECT * FROM tab_a WHERE id=OLD.id; All that I want to do is insert the records from OLD into a 2nd table. Any advice would be gratefully received. Bernie Warner JFDI Technology Ltd. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: handling NULLS in GiST
Oleg Bartunov <[EMAIL PROTECTED]> writes: > contrib/cube is just a bad example :-) In any case if you give an > interface to developer it's his responsibility to be aware of possible > errors. Developer has always a possibility to divide by zero. > We could change contrib/cube to be null-safe. My point is that as it stands, GIST is not honoring the defined interface for nulls. AFAICT you are relying on the called opclass routines to test for null pointers, which is not clean. (Among other things, it means that you cannot work with pass-by-value datatypes.) There has to be a separate isNull flag for each value. contrib/cube very possibly is broken, but that doesn't mean that the core GIST code isn't at fault too. > DirectFunctionCallN are already interface to > opclass support routines. But the FunctionCallN routines do not allow passing or returning NULL. That was a deliberate choice to preserve notational simplicity, because most of the places where they needed to be used didn't have to worry about NULLs. You do, so you can't use those routines. >> The macro-issue is what you intend to >> do with NULLs in the first place. I understand what btree does >> with them, but what's the corresponding concept for GIST? > if you mean first NULL keys in multikey GiST than just remove this tuple > from index because it's informativeless. btw, what btree does ? If you remove the tuple from the index then you're not storing NULLs. You need to pick a rule that defines where null rows will get placed in the index. For btree, the rule is "nulls sort after all non-nulls". regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: [GENERAL] 2 gig file size limit
(This question was answered several days ago on this list; please check the list archives before posting. I believe it's also in the FAQ.) > If PostgreSQL is run on a system that has a file size limit (2 > gig?), where might cause us to hit the limit? Postgres will never internally use files (e.g. for tables, indexes, etc) larger than 1GB -- at that point, the file is split. However, you might run into problems when you export the data from Pg to another source, such as if you pg_dump the contents of a database > 2GB. In that case, filter pg_dump through gzip or bzip2 to reduce the size of the dump. If that's still not enough, you can dump individual tables (with -t) or use 'split' to divide the dump into several files. Cheers, Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] ALTER TABLE ADD COLUMN column SERIAL -- unexpected results
Running: ALTER TABLE table ADD COLUMN column SERIAL; Defines a column as int4 but does not create the sequence or attempt to set the default value. Not a big deal, but I was surprised when the column values were null. -- Rod Taylor Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. BEGIN:VCARD VERSION:2.1 N:Taylor;Rod;B FN:Taylor, Rod B ORG:BarChord Entertainment Inc.;Network Operation and Development TITLE:Systems Engineer ADR;WORK:;;;Toronto;Ontario;;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Toronto, Ontario=0D=0ACanada X-WAB-GENDER:2 URL;WORK:http://www.barchord.com BDAY:19790401 EMAIL;INTERNET:[EMAIL PROTECTED] EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:20010716T164811Z END:VCARD ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: handling NULLS in GiST
On Mon, 16 Jul 2001, Tom Lane wrote: > Oleg Bartunov <[EMAIL PROTECTED]> writes: > > we noticed you changed gist.c to handle NULLS. It seems there is > > problem with your changes. > > I would like to see GIST upgraded to handle nulls, but at the moment > it's not null-safe. Try a few null entries, watch it core dump, if you > don't have that patch in place. (At least it does with the contrib/cube > opclass, didn't bother with any additional experiments.) We also would like to handle NULLs. All our codes handle NULLs properly. contrib/cube is just a bad example :-) In any case if you give an interface to developer it's his responsibility to be aware of possible errors. Developer has always a possibility to divide by zero. We could change contrib/cube to be null-safe. Also multikey split algorithm uses NULL to mark secondary (...) keys in tuple for optimization of page splitting and we don't like idea to rewrite algorithm. GiST interface functions (split, union - user-level functions) have a pointer to operand vector as argument. Operand vector can't be a NULL, but some operands in the vector could be NULL. > > At the very least you'd need to replace all the uses of > DirectFunctionCallN to invoke the opclass support routines > with code that is capable of detecting and signaling nulls. > That would allow non-null-safe opclass routines to be protected > by marking them "strict". vaguely understand :-) DirectFunctionCallN are already interface to opclass support routines. Do we need to build on yet another interface just to mark bad users routines ? What should we do with that 'strict' mark ? > > But that's a micro-issue. agreed, but I'd like to require people write null-safe contribs and remove your stopper. The macro-issue is what you intend to > do with NULLs in the first place. I understand what btree does > with them, but what's the corresponding concept for GIST? if you mean first NULL keys in multikey GiST than just remove this tuple from index because it's informativeless. btw, what btree does ? > regards, tom lane > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Planned changes to pg_am catalog
On Sat, 14 Jul 2001, Tom Lane wrote: > ... however, if you want to do some of the legwork yourself, here are > the ideas I had about what to do: OK. We'll dig into problem in august. At least we'll try. How many possible problems would arise after changing of pg_opclass ? Does existing code will handle this change somewhat automagically or we have to find and modify relevant code ? > > pg_opclass should have, not just one row for each distinct opclass name, > but one row for each supported combination of index AM and opclass name. > Doing it this way would allow us to put additional info in pg_opclass > rows --- right now, they're not really able to carry much information. > The particular bit of info I want to add is a "keytype" column. If this > is not InvalidOid then it gives the OID of the index column datatype to > be used when this opclass is selected. For keytype to be different from > data type, the amproc entries associated with the opclass would need to > include a conversion routine to produce the index value given the input > data columns --- ie, what the GIST code calls a compression routine. > (In essence, this would be a form of functional index, no?) Possibly > pg_opclass should also include the amprocnum of the conversion routine; > not sure how that ought to be handled. compress/decompress isn't a type conversion. for example, gist__int*_ops. indexed values and keytype are both int4 one dimensional arrays and compress/decompress in this case do some real work. > > Note that this change would have a number of implications for the > indexing of not only pg_opclass, but pg_amop and pg_amproc as well. > In particular, pg_amop could lose its amopid column, and pg_amproc > its amid column, since the opclass OID would be sufficient to indicate > which index AM is meant for any row in these tables. I have not worked > out all the details, but I believe that these tables would become a lot > more understandable this way. > > As for lossiness, I'm inclined to remove that column from pg_index > altogether. Instead, it should be a column in pg_amop, indicating that > an index must be treated as lossy *for a particular operator in a > particular opclass*. Per previous discussion, this is the right level > for the concept. AFAIR, we could drop the WITH clause from CREATE INDEX > altogether if we did this, which I think is the right thing --- the user > should not be responsible for telling the system the properties of an > index type and opclass. > > If you have time to start working out the details, that'd be great. > I won't have time for it before mid-August probably. > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Planned changes to pg_am catalog
Oleg Bartunov <[EMAIL PROTECTED]> writes: > How many possible problems would arise after changing of pg_opclass ? > Does existing code will handle this change somewhat automagically > or we have to find and modify relevant code ? There's a fair amount of code that would need to be touched. One thing I realized just last night is that some routines use the tables to ask questions like "is this operator OID a member of any btree opclass, and if so which opclass and strategy number?" This is a relatively simple sequential scan over the pg_amop table at the moment. But if the amid column were removed, it'd require a join with pg_opclass, which might be good from the point of view of normalization theory but is a bit of a pain in the neck to program in low-level code. It might also be nice if we could use an index instead of a seq scan (although pg_amop is not so large that this is essential). So all the places that touch these tables need to be identified, and a design invented that doesn't make any of them unreasonably complex. Possibly we should leave the amid column in pg_amop, ie, deliberately keep the tables unnormalized, to make some of these lookups easier. > compress/decompress isn't a type conversion. for example, > gist__int*_ops. indexed values and keytype are both int4 one dimensional > arrays and compress/decompress in this case do some real work. Okay, so the presence of a non-null keytype field should indicate that a conversion routine is to be invoked, even if it's the same type as the underlying datatype. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: handling NULLS in GiST
Oleg Bartunov <[EMAIL PROTECTED]> writes: > we noticed you changed gist.c to handle NULLS. It seems there is > problem with your changes. I would like to see GIST upgraded to handle nulls, but at the moment it's not null-safe. Try a few null entries, watch it core dump, if you don't have that patch in place. (At least it does with the contrib/cube opclass, didn't bother with any additional experiments.) At the very least you'd need to replace all the uses of DirectFunctionCallN to invoke the opclass support routines with code that is capable of detecting and signaling nulls. That would allow non-null-safe opclass routines to be protected by marking them "strict". But that's a micro-issue. The macro-issue is what you intend to do with NULLs in the first place. I understand what btree does with them, but what's the corresponding concept for GIST? > I remind we have choosen to leave NULLs because vacuum complained about > different number of tuples in heap and index and all our opclasses work > correctly with NULLs. Did you change vacuum code so it will not complain ? Yes. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
AW: [HACKERS] handling NULLS in GiST
> we noticed you changed gist.c to handle NULLS. It seems there is > problem with your changes. > I remind we have choosen to leave NULLs because vacuum complained about > different number of tuples in heap and index and all our opclasses work > correctly with NULLs. Did you change vacuum code so it will not complain ? If the opclasses handle NULLs, then they should be in the index. Leaving them out would imho be better handled with the partial index code. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] handling NULLS in GiST
Tom,
we noticed you changed gist.c to handle NULLS. It seems there is
problem with your changes.
in gist.c
/* GIST indexes don't index nulls, see notes in gistinsert */
if (! IndexTupleHasNulls(itup))
{
/*
... skipped
/*
* Currently, GIST indexes do not support indexing NULLs; considerable
* infrastructure work would have to be done to do anything reasonable
* with a NULL.
*/
if (IndexTupleHasNulls(itup))
{
While it's ok for single key but for multikey indexes removing tuple with NULL
looks not right. Consider (a,b,c) where C is NULL. Your changes would
remove tuple and it would be impossible to find (a,b) using this index.
Did you think about this particular case ?
I remind we have choosen to leave NULLs because vacuum complained about
different number of tuples in heap and index and all our opclasses work
correctly with NULLs. Did you change vacuum code so it will not complain ?
In principle, if you insist on your approach, we propose to extend it
to multikey case by removing tuple if and only if leading keys are NULLs
What do you think ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] NetBSD 1.5.1(HP300)
in testing CVS tip(sort of), I found that you need -lcurses with -ledit on NetBSD 1.5.1. _tputs in undefined otherwise. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] OLD in Triggers
Hi, Can anyone confirm whether I can do something like the following in a PL/pgsql trigger ( on table tab_a ) SELECT INTO tab_b * FROM OLD; or do I have to do - INSERT INTO tab_b SELECT * FROM tab_a WHERE id=OLD.id; All that I want to do is insert the records from OLD into a 2nd table. Any advice would be gratefully received. Bernie Warner JFDI Technology Ltd. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Translators wanted
Peter Eisentraut wrote: > Please arrange yourselves with other volunteering speakers of your > language. Results should be sent to the pgsql-patches list. Any other Italian-speaking willing to do the job? I fear I won't have a lot of time to allocate even if I'm very interested. -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
