On Thu, Feb 19, 2004 at 11:57:33AM -0800, Shelby Cain wrote:
> I'm coming from a Pro*C background so I'm not entirely
> certain whether what I am attempting is simply not
> allowed in ecpg or not.
Well it should be. :-)
Thanks for reporting the bug. I just committed a fix to HEAD and
REL7_4_STABL
"Flavio Casadei D. C." <[EMAIL PROTECTED]> writes:
> create table foo (
> id integer not null primary key,
> name char(6) not null,
> value varchar(255)
> );
> insert into foo values (1,'FLAVIO','hi!');
> insert into foo values (2,'FLA ' ,'hi!');
> insert into foo values (3,' ','hi!');
> ins
The following bug has been logged online:
Bug reference: 1161
Logged by: Martin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:User permissions are kept, even if user is dropped
Details:
Hi,
dropping and creating a
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> /* this statement will reverse the order of CURRVAL()/NEXTVAL() to match the
> column order of the table */
> INSERT INTO testing (col_b, col_a) VALUES (NEXTVAL('seq'), CURRVAL('seq'));
This is not a bug. The order of evaluation of select-lis
Hi,
this is just a me too message. We have 7.4.2 running which
was build from fink (I guess same compiler settings).
My investigation so far is that:
- the system will eat more and more memory and will start swapping
to hard disk
- no performance hits so far (I haven't noticed any)
- the system w
"Martin Langhoff (Catalyst IT)" <[EMAIL PROTECTED]> writes:
> Thanks for the clarification. I am curious, however: I can't find a
> means to achieve the same effect in a deterministic manner. Any pointers?
How about
SELECT nextval('seq'); -- ignore result
INSERT INTO ... VALUES (currval('
Hi again!
On 2004-05-25 15:13 -0400, Tom Lane wrote:
> I said:
> > I would suggest adding more paranoia along these lines:
>
> Actually the correct patch is as per attached. Even without a core
> dump, the original code would not print the token that was really
> causing the problem :-(. Please
Christian van der leeden <[EMAIL PROTECTED]> writes:
> this is just a me too message.
Neither one of you has provided any information that would let anyone
else even guess where to look for the problem :-(
For starters, which process or processes is eating memory? (see top(1))
Martin Pitt <[EMAIL PROTECTED]> writes:
> The submitter of this bug eventually reported back (there was a
> problem with his email address) and tested the updated package (with
> your patch); unfortunately it seems that the patch did not improve the
> output very much :-( He wrote:
I didn't expect
Folks,
Is there any known issues with index file corruption in the event of a
power-out during REINDEX with 7.2.4?
I *think* the problem is this client's peculiar hardware, but wanted to
eliminate any potential known issues.
--
-Josh Berkus
__AGLIO DATABASE SOLUTIONS_
10 matches
Mail list logo
