On Sun, 24 Aug 2008 13:37:11 +0200
Alban Hertroys [EMAIL PROTECTED] wrote:
Is it going to make things faster if I:
delete from s;
reindex table s;
Why do you think this step would help you any? There's no index
on p to begin with. You'd just be reindexing the auto-generated
unique
On Sun, 24 Aug 2008 17:26:24 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Ivan Sergio Borgonovo wrote:
I was trying to drop a serial.
Dropped the default for a column.
Now it seems I can't drop the sequence since I incurred in:
I am going to try to get 8.3.3 to work for me.
1.
I have read that to install 8.3 on Vista that you should disable UAC. If I do
so, can I turn it back on again AFTER the postgres is installed ?
Hi.
I have googled and googled for good, simple instructions to upgrade
from 8.2.3 to 8.3.3 (latest stable at this time?)
I am on a Cpanel interface. Use Apache and PHP for most of my websites.
This seems to be the most often quoted resource on forums etc:
Hi,
Phoenix Kiula wrote:
Hi.
I have googled and googled for good, simple instructions to upgrade
from 8.2.3 to 8.3.3 (latest stable at this time?)
I am on a Cpanel interface. Use Apache and PHP for most of my websites.
This seems to be the most often quoted resource on forums etc:
Normally we don't use the packages from the distributions. They're
mostly outdated and installation ov two or more versions of Postgres
isn't that easy normally in this case. We've a directory structure which
allows
us to install and startup two or more versions in parallel. I haven't
tried
On Mon, Aug 25, 2008 at 11:34:00AM +0200, Tino Wildenhain wrote:
(e.g. pg_dump | pg_restore to avoid wasting space 2 times)
then run slony to permanently update the last bits
If you're going to run slony, then the pg_dump|pg_restore step is
completely wasted. Slony will restore all the data
Andrew Sullivan wrote:
On Mon, Aug 25, 2008 at 11:34:00AM +0200, Tino Wildenhain wrote:
(e.g. pg_dump | pg_restore to avoid wasting space 2 times)
then run slony to permanently update the last bits
If you're going to run slony, then the pg_dump|pg_restore step is
completely wasted. Slony
Ow Mun Heng [EMAIL PROTECTED] writes:
On Mon, 2008-08-25 at 12:23 +0800, Ow Mun Heng wrote:
CREATE INDEX idx_d_trh_code_id_partial
ON xmms.d_trh_table
USING btree
(code_id) where code_id not in ('P000','000') and code_id is not null;
ERROR: functions in index predicate must be marked
By bad data, I mean a character that's not UTF8, such as hex 98.
As far as I can tell, pg_dump is the tool to use. But it has
serious drawbacks.
If you dump in the custom format, the data is compressed (nice) and
includes large objects (very nice). But, from my tests and the postings of
others,
Ivan Sergio Borgonovo [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] wrote:
If you're feeling corageous, you can remove the pg_depend entries
for that sequence. Make sure to try it in a transaction and drop
I'd like to understand better the risks of being courageous?
I think my
John T. Dow [EMAIL PROTECTED] writes:
If you dump in plain text format, you can at least inspect the dumped
data and fix it manually or with iconv. But the plain text
format doesn't support large objects (again, not nice).
It does in 8.1 and later ...
Also, neither of these methods gets
On Thu, 2008-08-21 at 13:53 -0600, Scott Marlowe wrote:
Regular SERIAL type is limited to a 32 bit int. BIGSERIAL uses a 64
bit int.
I think one of the things that would be offsetting is the size
difference between the two types (32 vs 64 bits, 5 foreign keys, and a
billion rows or so makes
Hi!
I'm a newbie and want to startup my just installed postgres :
* 8.3-community
* SPARC
* Solaris 10
it answers that it has to find postgresql.conf but I can't find it anywere
do I have to write it specifying the most basic options?
On Mon, 25 Aug 2008 12:07:23 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Ivan Sergio Borgonovo [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] wrote:
If you're feeling corageous, you can remove the pg_depend
entries for that sequence. Make sure to try it in a
transaction and drop
Tom
My mistake in not realizing that 8.1 and later can dump large objects in the
plain text format. I guess when searching for answers to a problem, the posted
information doesn't always specify the version. So, sorry about that.
But the plain text format still has serious problems in that the
On Mon, Aug 25, 2008 at 10:23 AM, Mark Roberts
[EMAIL PROTECTED] wrote:
On Thu, 2008-08-21 at 13:53 -0600, Scott Marlowe wrote:
Regular SERIAL type is limited to a 32 bit int. BIGSERIAL uses a 64
bit int.
I think one of the things that would be offsetting is the size
difference between the
On Mon, 25 Aug 2008 10:21:54 -0400
John T. Dow [EMAIL PROTECTED] wrote:
By bad data, I mean a character that's not UTF8, such as hex 98.
As far as I can tell, pg_dump is the tool to use. But it has
serious drawbacks.
If you dump in the custom format, the data is compressed (nice) and
On Thu, Aug 21, 2008 at 3:05 AM, Shashwat_Nigam
[EMAIL PROTECTED] wrote:
Dear Vishal
Thanks for the help but by doing this an error is generated at the time when
the user is trying to log in with the following message:
Access to database denied
The server doesn't grant access to the
Joshua
The TOC feature sounds good, as does converting a single table to plain text.
But I can't find documentation for the TOC feature under pg_dump or pg_restore.
I'm looking in postgresql-8.2.1-US.pdf.
Neither could I see anything about converting a single table to a plain text
dump.
On Mon, 25 Aug 2008 13:37:13 -0400
John T. Dow [EMAIL PROTECTED] wrote:
Joshua
The TOC feature sounds good, as does converting a single table to
plain text.
But I can't find documentation for the TOC feature under pg_dump or
pg_restore. I'm looking in postgresql-8.2.1-US.pdf.
The
Hi,
Yuri Huitron Alvarado wrote:
Hi!
I'm a newbie and want to startup my just installed postgres :
* 8.3-community
* SPARC
* Solaris 10
it answers that it has to find postgresql.conf but I can't find it anywere
do I have to write it specifying the most basic options?
I cant say much about
PostgreSQL 8.3 on Windows. I have the table below which has a before
insert trigger. The CREATE TRIGGER statement and the trigger function
are also shown below. When I insert a row into this table using pgAdmin
III and the INSERT statement
insert into note.category (category_id, category)
Ivan Sergio Borgonovo wrote, On 25-Aug-2008 18:48:
On Mon, 25 Aug 2008 12:07:23 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Ivan Sergio Borgonovo [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] wrote:
If you're feeling corageous, you can remove the pg_depend
entries for that sequence.
On Mon, 2008-08-25 at 11:02 -0600, Scott Marlowe wrote:
Well, of course a 64 bit int is gonna be bigger than a 32 bit, but
with alignment issues and on 64 bit hardware, I'm guessing the
difference isn't exactly twice as slow / twice as much storage. And
it's way faster than a GUID which was
Joshua
Thank you very much for answering these various questions.
I guess the compressed format is the best overall solution, except for roles. I
find myself having a table with other information about users (application
specific user type, etc) so perhaps the thing to do is record enough
On Mon, 25 Aug 2008 17:05:53 -0400
John T. Dow [EMAIL PROTECTED] wrote:
Joshua
Thank you very much for answering these various questions.
I guess the compressed format is the best overall solution, except
for roles. I find myself having a table with other information about
users
Sorry, I missed that. Thanks again.
Now to put this all into effect.
John
On Mon, 25 Aug 2008 14:25:12 -0700, Joshua Drake wrote:
On Mon, 25 Aug 2008 17:05:53 -0400
John T. Dow [EMAIL PROTECTED] wrote:
Joshua
Thank you very much for answering these various questions.
I guess the
Bill [EMAIL PROTECTED] writes:
PostgreSQL 8.3 on Windows. I have the table below which has a before
insert trigger. The CREATE TRIGGER statement and the trigger function
are also shown below.
The script you show attempts to create the trigger before creating the
function, which of course
Tom Lane wrote:
Bill [EMAIL PROTECTED] writes:
PostgreSQL 8.3 on Windows. I have the table below which has a before
insert trigger. The CREATE TRIGGER statement and the trigger function
are also shown below.
The script you show attempts to create the trigger before creating the
Bill [EMAIL PROTECTED] writes:
In a newsgroup posting someone suggested that constraint checks on
domains occur before the before insert trigger.
Yeah, that is the case, but if a domain check was failing then the
row wouldn't get inserted, so I'm not clear on how this matches up
with your
Tom Lane wrote:
Bill [EMAIL PROTECTED] writes:
In a newsgroup posting someone suggested that constraint checks on
domains occur before the before insert trigger.
Yeah, that is the case, but if a domain check was failing then the
row wouldn't get inserted, so I'm not clear on how this
Bill [EMAIL PROTECTED] writes:
Is it possible to create a type and use that instead of the domain or
will I have the same problem with a type?
You'd have the same problem. By the time the trigger sees it, the row
has already been converted to the table's column datatype(s), so any
exception
You'd have the same problem. By the time the trigger sees it, the row
has already been converted to the table's column datatype(s), so any
exception associated with a datatype or domain would be thrown already.
A lot of people seem to have trouble with this concept; I dunno what
data
If you're going to run slony, then the pg_dump|pg_restore step is
completely wasted. Slony will restore all the data again. You do
need to run pg_dump -s, of course.
Thanks to everyone who replied. We have no experience with this
Slony. Any simple instructions on installing it and
On Tue, 26 Aug 2008 09:25:09 +0800
Phoenix Kiula [EMAIL PROTECTED] wrote:
Slony. Any simple instructions on installing it and getting it
working?
Why is PG so complex! It's a such a lovely database. If only at least
the installation and upgrade could be made more humane..
Well the
Brian Green wrote:
I am going to try to get 8.3.3 to work for me.
1.
I have read that to install 8.3 on Vista that you should disable UAC. If I do
so, can I turn it back on again AFTER the postgres is installed
Tom Lane wrote:
Bill [EMAIL PROTECTED] writes:
Is it possible to create a type and use that instead of the domain or
will I have the same problem with a type?
You'd have the same problem. By the time the trigger sees it, the row
has already been converted to the table's column
On Mon, Aug 25, 2008 at 7:25 PM, Phoenix Kiula [EMAIL PROTECTED] wrote:
If you're going to run slony, then the pg_dump|pg_restore step is
completely wasted. Slony will restore all the data again. You do
need to run pg_dump -s, of course.
Thanks to everyone who replied. We have no
Bill [EMAIL PROTECTED] writes:
I removed the domain from the category_id and version columns leaving
the following table, trigger function and trigger. The trigger function
is still not called when I insert a new row. Any other ideas?
You're still expecting the trigger to get invoked before
Tom Lane wrote:
Bill [EMAIL PROTECTED] writes:
I removed the domain from the category_id and version columns leaving
the following table, trigger function and trigger. The trigger function
is still not called when I insert a new row. Any other ideas?
You're still expecting the
Bill [EMAIL PROTECTED] writes:
The thing that has me confused is that the following table, trigger and
trigger function work perfectly and the primary key for this table is
also bigint not null.
Actually, after looking closer, I think the problem with your previous
example is that you
Klint Gore [EMAIL PROTECTED] writes:
... With the not null definition in the domain, this
blows up before anything else has a chance.
Right. Forming the proposed row-to-insert involves coercing the data to
the correct data types, and for domain types enforcing the domain
constraints is seen
Date: Mon, 25 Aug 2008 11:08:14 -0600 From: [EMAIL PROTECTED] To: [EMAIL
PROTECTED] Subject: Re: [ADMIN] Regarding access to a user CC: [EMAIL
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
pgsql-general@postgresql.org; [EMAIL PROTECTED] On Thu, Aug 21, 2008 at
3:05 AM,
On Mon, 2008-08-25 at 10:18 -0400, Tom Lane wrote:
Ow Mun Heng [EMAIL PROTECTED] writes:
On Mon, 2008-08-25 at 12:23 +0800, Ow Mun Heng wrote:
CREATE INDEX idx_d_trh_code_id_partial
ON xmms.d_trh_table
USING btree
(code_id) where code_id not in ('P000','000') and code_id is not null;
Tom Lane wrote:
Bill [EMAIL PROTECTED] writes:
The thing that has me confused is that the following table, trigger and
trigger function work perfectly and the primary key for this table is
also bigint not null.
Actually, after looking closer, I think the problem with your previous
Ow Mun Heng [EMAIL PROTECTED] writes:
On Mon, 2008-08-25 at 10:18 -0400, Tom Lane wrote:
I suppose code_id is varchar or some such?
Yep
After a few more investigation on the usefulness of the partial indexes,
I found that, it really isn't all that useful, perhaps some experts can
shed
Bill wrote:
The thing that has me confused is that the following table, trigger
and trigger function work perfectly and the primary key for this table
is also bigint not null. I added a bigint not null domain to this
schema and changed the data type of the key to the domain and then I
get the
48 matches
Mail list logo
