On Wed, Jul 14, 2004 at 07:40:49 +0530,
Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> hi,
> can anyone tell me which is the earliest version of postgres to support
> schemas
7.3
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands
hi,
can anyone tell me which is the earliest version of postgres to support
schemas
--
regards
kg
http://www.onlineindianhotels.net - hotel bookings reservations in over 4600
hotels in India
http://www.ootygolfclub.org
---(end of broadcast)---
TI
I apologize for the following stupid question. I have been doing some
searching and haven't found anything really helpful.
The problem is that postgres (7.4.2) keeps choosing to do a sequential
scan on a table when an index scan would be significantly faster.
The queries that I'm using look at
Dear Rod,
That sounds as good as simple ;) As for as patching, we do something like
that. Developed a PHP script that compares schema files (not dumps, but
source codes instead) to the actual. Say, it creates a temp table and
compares it to the existing one, examining pg_attributes, pg_indexes,
pg
On Tue, 2004-07-13 at 13:42, SZŰCS Gábor wrote:
> Dear Rod,
>
> Thanks. It'll be a pain to have two versions between the prod and devel
> servers, but I'll forward this info to the chief.
You can make this part easier on yourself.
Dump the structure from production and migrate it to devel (fix t
Dear Gurus,
Dumping from 7.3 to 7.4 seems to omit some of the COPY commands, without any
warning or error. The table is created, there are notices about indexes in
the log, but COPY doesn't seem to happen-- the table remains empty at the
end of the dump. As far as we discovered, these are a couple
Dear Rod,
Thanks. It'll be a pain to have two versions between the prod and devel
servers, but I'll forward this info to the chief.
Thanks again,
G.
%--- cut here ---%
\end
- Original Message -
From: "Rod Taylor" <[EMAIL PROTECTED]>
Sent: Tuesday,
> Checked, and So do you say, this problem persists in dbs dumped from 7.4 to
> 7.4 too? i.e. upgrading to 7.4 (which we tested for quite some time now)
> won't help?
There may have been some minor fiddling to make it easier, but I
wouldn't call it fixed by any means.
> trying dump confirmed thi
Thanks Rod.
Checked, and So do you say, this problem persists in dbs dumped from 7.4 to
7.4 too? i.e. upgrading to 7.4 (which we tested for quite some time now)
won't help?
(...)
trying dump confirmed this :( Even tried adding a line to pg_depend but
didn't seem to change anything.
G.
%---
> If you decrypt the data on the database, the sysadmin can see it.
Hm, you are right. If one does decrypt the data on the database you have to sent the
password to postgresql and so a administrator of the database could easily grasb the
password.
So the only way to go, would be to perform en/d
On Tue, Jul 13, 2004 at 11:35:57 +0200,
Daniel Struck <[EMAIL PROTECTED]> wrote:
> > Keeping the system administrator from seeing the data while making it
> > searchable is difficult. To do this you need to encrypt the data on
> > the client side using a key the client has (and this key has to be
> Keeping the system administrator from seeing the data while making it
> searchable is difficult. To do this you need to encrypt the data on
> the client side using a key the client has (and this key has to be
> protected from loss) and the only searches you can do are equality
> searches using a
O kyrios Rajesh Kumar Mallah egrapse stis Jul 13, 2004 :
> Achilleus Mantzios wrote:
>
> >O kyrios Rajesh Kumar Mallah egrapse stis Jul 12, 2004 :
> >
> >
> >
> >>Achilleus Mantzios wrote:
> >>
> >>
> >>
> >>>O kyrios Rajesh Kumar Mallah egrapse stis Jul 12, 2004 :
> >>>
> >>>
> >>>
> >>>
13 matches
Mail list logo
