Sean Chittenden <[EMAIL PROTECTED]> writes:
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 135137 deleted while still in use
Hm. Anyone else seeing this? I just did a dozen or so "mak
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > PS What's the dilly with the server(s)? I haven't gotten a commit
> >message all day, but CVSup and anoncvs picked up the change.
>
> Well, the CVS master server has been pretty much 100% through this
> whole rigmarole (kudos to Marc for keepi
Sean Chittenden <[EMAIL PROTECTED]> writes:
> PS What's the dilly with the server(s)? I haven't gotten a commit
>message all day, but CVSup and anoncvs picked up the change.
Well, the CVS master server has been pretty much 100% through this
whole rigmarole (kudos to Marc for keeping up what *
> > Don't know whether or not this is preferred here or on hackers,
> > but, I just updated my development database to a snapshot from
> > today and have been getting the following backtrace when importing
> > a dump from before earlier today. It looks as though something's
> > tromping on variabl
[EMAIL PROTECTED] writes:
> NOTICE: Error occurred while executing PL/pgSQL function apaga_constraint
> NOTICE: line 20 at for over select rows
> ERROR: parser: parse error at or near "$1"
> DECLARE
> qtdINTEGER;
^^^
> FOR registro IN
> SELECT t.tgrelid, COUNT(t.tgn
Hi,
I couldn't find the logical error in my function, so I was wondering if there
could be a bug. The function is created, but when I try to use it I get the
following error message:
NOTICE: Error occurred while executing PL/pgSQL function apaga_constraint
NOTICE: line 20 at for over select row
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Don't know whether or not this is preferred here or on hackers, but, I
> just updated my development database to a snapshot from today and have
> been getting the following backtrace when importing a dump from before
> earlier today. It looks as though
Don't know whether or not this is preferred here or on hackers, but, I
just updated my development database to a snapshot from today and have
been getting the following backtrace when importing a dump from before
earlier today. It looks as though something's tromping on variable.
pid 68526 (postg
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Hrm... this limitation makes temporary tables that drop on commit +
> pl/pgsql unusable beyond the 1st transaction. Is there a mechanism to
> test to see if a relation in a plan is a temporary table? It seems as
> though in pl_exec.c that around 1926
> > CREATE FUNCTION s.f()
> > RETURNS BIGINT
> > EXTERNAL SECURITY DEFINER
> > AS '
> > BEGIN
> > EXECUTE ''CREATE LOCAL TEMP TABLE t (
> > a TEXT NOT NULL,
> > b TEXT
> > ) WITHOUT OIDS ON COMMIT DROP;'';
> > EXECUTE '
Bruce Momjian wrote:
JDBC guys, what do you think of this fix? I don't see the change in CVS.
Well, it also fails if you have the old postgresql.jar in your java
jre/lib/ext as well and there is no fixed way to exclude it that I know
of. In general, the old jar should not be in any place that
11 matches
Mail list logo
