Hi,
I want to store confidential data. I created a user with createdb
permission.
How can I prevent others accessing tables created by this user?
Regards,
Rekha.
--
Rekha Pai
Senior Software Consultant
Anyone have some idea how to do this? I am able to install my Win32
application but the postgeSQL install will not work. Any help or at
least a starting point would be appreciated.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
Now THIS is a new one for me! I have no idea where to even start. Does
anyone know how to look for the error? Below is the query and what I believe
are the related log entries.
Any help will be rewarded with heartfelt gratitude and praise, or you can
just come to Montreal and hit me up for a
"PostgreSQL 8.3.6, compiled by Visual C++ build 1400"
I see the log entries for 'loaded library
"$libdir/plugins/plugin_debugger.dll"'
Is there any cost or downside associated with this? There are suspicions the
server is quite the CPU hog.
--
Sent via pgsql-general mailing list (pgsql-gen
On Sunday 14 March 2010 1:09:37 pm fka...@googlemail.com wrote:
> Adrian Klaver:
> > > AFAIK the dump/restore does not rebuild the original OID
> > > values, so all relations built accross OIDs fail.
> > >
> > > (1)
> > > Is there a way to keep the original OID values somehow?
> >
> > From here:
>
That looks like the fix for this, thanks! I will try to upgrade soon.
-- Gordon
On Sun, Mar 14, 2010 at 7:43 AM, Alvaro Herrera
wrote:
> Gordon Shannon escribió:
> > Ah, now I see what you meant. Forgive me, I thought you were referring
> to
> > the pg_autovacuum table in 8.3 where you have to
Adrian Klaver:
> > AFAIK the dump/restore does not rebuild the original OID
> > values, so all relations built accross OIDs fail.
> >
> > (1)
> > Is there a way to keep the original OID values somehow?
>
> From here:
> http://www.postgresql.org/docs/8.4/interactive/app-pgdump.html
>
> -o
> --oid
Thomas Kellerer writes:
> Belka Lambda wrote on 14.03.2010 01:24:
>> Is there a way to "nicely" determine a default value of a table column? A
>> function, which could be used, like:
> The defaults are store in pg_attrdef, the corresponding column definitions in
> pg_attribute.
> So you would
Belka Lambda wrote on 14.03.2010 01:24:
Hi everyone!
Is there a way to "nicely" determine a default value of a table column? A
function, which could be used, like:
The defaults are store in pg_attrdef, the corresponding column definitions in
pg_attribute.
So you would need to do a join betw
On Sunday 14 March 2010 9:21:06 am fka...@googlemail.com wrote:
> Hi all,
>
> I have several databases here which I would like to update
> from 8.2 to 8.4, which in turn requires a dump/restore.
>
> However, the databases are OIDs depending, so, some values
> depend on OIDs in other tables.
>
> AFA
Hi everyone!
Is there a way to "nicely" determine a default value of a table column? A
function, which could be used, like:
SELECT default_of('my_table.my_integer_column') :: integer;
?
I scanned pg_proc table:
===
postgres=# select proname from pg_proc where pro
On Sat, Mar 13, 2010 at 3:34 AM, A B wrote:
> 3Ware SAS 9690SA-8i 512 MB BBU
> Adaptec SAS Raid 5805 256 MB BBU
> LSI MegaRaid SAS 8708 128 MB BBU
>
When faced with the choice of Adaptec vs. anything else, I choose
anything else. When faced with the choice of LSI vs anything else, I
look really
On 14/03/2010 16:21, fka...@googlemail.com wrote:
> (2)
> If I need to go the long way and replace the OIDs with
> SERIALs first, updating all relations to it etc: Would a
> dump/restore then restore the original values in a SERIAL
> column?
So-called SERIAL types are actually just integer column
Hi all,
I have several databases here which I would like to update
from 8.2 to 8.4, which in turn requires a dump/restore.
However, the databases are OIDs depending, so, some values
depend on OIDs in other tables.
AFAIK the dump/restore does not rebuild the original OID
values, so all relations
Gordon Shannon escribió:
> Ah, now I see what you meant. Forgive me, I thought you were referring to
> the pg_autovacuum table in 8.3 where you have to specifiy something for each
> column, and -1 says use the default. It appears in 8.4.0 I have to
> explicitly set ALL (?) other storage parameter
A B wrote:
Hi there!
I'm trying to comprehend the current status of filesystem settings and
PostgreSQL settings.
If I run on a machine (using Linux and ext3) with no battery backed
raid controller then I should use fsync=on and disable the write cache
on my harddrives to avoid corruption.
If
Hi there!
I'm trying to comprehend the current status of filesystem settings and
PostgreSQL settings.
If I run on a machine (using Linux and ext3) with no battery backed
raid controller then I should use fsync=on and disable the write cache
on my harddrives to avoid corruption.
If I had a contr
17 matches
Mail list logo
