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
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
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
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
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
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
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
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 =
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
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:
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
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
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
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
*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
[EMAIL PROTECTED] (Nathan Myers) writes:
Considering the Apache comment about some systems truncating instead
of limiting... 10xff 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
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
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
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
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
/*
*
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
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
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
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
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
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
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 15
configure: failed program was:
#line 7170 configure
#include confdefs.h
int main() { return 0; }
$
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 type object [RESTRICT |
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
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
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
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
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
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
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 type object
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 type object [RESTRICT | CASCADE]
to make use of dependency info.
That was me.
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
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
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
(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
40 matches
Mail list logo
