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 appl
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
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_augme
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 use
[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 t
> *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
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?
>
With
> 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 t
> 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 th
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 laisse
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 tabl
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 sugges
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
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 wa
> 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 ob
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 you
> 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
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 el
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_depen
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 el
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 |
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
> "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
> 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 189
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 r
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:
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 wi
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
s
"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 correspond
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 con
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
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-em
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 ty
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 2
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
(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 (
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 sleep
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 entri
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
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 t
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 pa
> 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 co
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
/*
* Curre
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,
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 2
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.
46 matches
Mail list logo
