On Wed, 8 Nov 2000, [iso-8859-1] Mickaël Jouanne wrote:
> Hello !
>
> I want to do a VACUUM ANALYSE on some tables but when i do :
>
> EDEN=> VACUUM ANALYSE cvdb;
> ERROR: parser: parse error at or near "cvdb"
Yes, it is a spelling difference.
vacuum verbose analyze tabname;
> But cvdb is
On Wed, Nov 08, 2000 at 05:51:52PM +, Oliver Elphick wrote:
> =?iso-8859-1?Q?Micka=EBl_Jouanne?= wrote:
> >Hello !
> >
> >I want to do a VACUUM ANALYSE on some tables but when i do :
> >
> >EDEN=> VACUUM ANALYSE cvdb;
> >ERROR: parser: parse error at or near "cvdb"
> >
> >But
> Some time ago I saw the someone give an example of how to combine a
> query result with test using sql.
> What i have is a table with f_name varchar l_name varchar and I want the
> result to say [EMAIL PROTECTED]
> Is this possible I will redirect the output to a textfile using the \o
> option.
Some time ago I saw the someone give an example of how to combine a
query result with test using sql.
What i have is a table with f_name varchar l_name varchar and I want the
result to say [EMAIL PROTECTED]
Is this possible I will redirect the output to a textfile using the \o
option.
Thanks in ad
Matt Beauregard <[EMAIL PROTECTED]> writes:
>> Since these are only views, the datafiles underlying them would be empty
>> anyway --- so you can recreate the datafiles just by doing
>> "touch $PGDATA/base/template1/pg_user" etc.
> I've touched pg_user and pg_group but the db still won't find them
On Wed, Nov 08, 2000 at 10:03:05PM -0500, Tom Lane wrote:
> Matt Beauregard <[EMAIL PROTECTED]> writes:
> NOTICE: mdopen: couldn't open pg_user: No such file or directory
> >>
> >> This is strange in itself. There should be an (empty) file named
> >> pg_user in your $PGDATA/base/template1
[EMAIL PROTECTED] writes:
> I'm trying to dump a database from a 6.5 PGSQL server so that I can put it
> on a new server that is running the latest version. The problem is that
> when I try to dump it gives me this error:
> [jesse@titan jesse]$ pg_dump rat > rat.db
> dumpSequence(reporters_idnum
On Wed, 8 Nov 2000, Luis [UNKNOWN] Magaña wrote:
> insert into employee(title,first_name,start_date,charge) values('Mr.
>X','Smith',date(now()),'None');
> insert into employee(title,first_name,start_date,charge) values('Mr.
>Y','Smith',date(now()),'None');
> insert into employee(title,first_na
Hello everyone,
I'm trying to dump a database from a 6.5 PGSQL server so that I can put it
on a new server that is running the latest version. The problem is that
when I try to dump it gives me this error:
[jesse@titan jesse]$ pg_dump rat > rat.db
dumpSequence(reporters_idnum_seq): 0 (!= 1) tup
Matt Beauregard <[EMAIL PROTECTED]> writes:
NOTICE: mdopen: couldn't open pg_user: No such file or directory
>>
>> This is strange in itself. There should be an (empty) file named
>> pg_user in your $PGDATA/base/template1 directory --- is there?
>> What about pg_views?
> Neither are there
Hi:
Have this curious situation and would like some help from you:
Create an employee table:
CREATE TABLE employee(
id_employee SERIAL PRIMARY KEY,
sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
start_date DATE NOT NULL,
charge VARCHAR(50) NOT NULL,
last_name VARCHAR(50
Hi,
I've noticed that Postgresql stores its data with an OID for each line
inserted. I wonder how I could find the difference between the large objects
(OID) inserted by the users and the OID which are actually a line in the DB.
I mean, is there a special table which stores only the internal DB
On Wed, Nov 08, 2000 at 08:40:08PM -0500, Tom Lane wrote:
> Matt Beauregard <[EMAIL PROTECTED]> writes:
> >> The plot thickens ... what did you say the error message was
> > exactly?
>
> > !759 marauder@bofh:~$ pg_dump -h tweedledee ds
> > getTypes(): SELECT failed. Explanation from backend: 'ER
I want to find out how confused I am. ;-)
I'm testing something on a Postgres 7.0.2 database. I made a small table with
two columns, one serial and the other TEXT, and tried to make serveral
inserts with PHP.
Some went OK, until I tried to insert a large amount of text. It failed. Of
course, I
Yup, a full VACUUM analyze was done on the table. The problem seems to be
that 95% of processor time is spent in the kernal opening and closing the
same table file. This does seem a little strange. Could this be a problem
with the code? I've also tried a full reinstall, but to no avail.
Loz
On T
I think so
what the exact impact of this variable ?
Thanks for your help
- Original Message -
From: Tom Lane <[EMAIL PROTECTED]>
To: Michaël Fiey <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, November 08, 2000 6:36 AM
Subject: Re: [GENERAL] PGBUFFERS
> =?iso-8859-1?Q?Mich
Jonathan Ellis wrote:
> I tried mailing this last week, but I think it didn't get sent:
>
> I defined a procedure
>
> CREATE FUNCTION meta_class (varchar) RETURNS varchar AS '
> ...
> ' LANGUAGE 'pltcl';
>
> This works fine. But when I want to call it from another tcl procedure I
> get errors:
>
17 matches
Mail list logo
