I have a question about pg_statistic: Can we safely remove all records
from pg_statistic? In my understanding, we could do it safely, since
the table is just a result holder of vacuum analyze.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 1: subscri
I am trying to add another authentication mechanism to PostgreSQL... And,
in doing that, I need to verify the existance of an user within PG. Short
of hacking together code from verify_password(), is there any way to check
if a user exists in postgresql? (The actuall password verification will be
It's nothing but unused definitions. PostgreSQL7.1 compiles and works for me.
I got following warnings for PL/PgSQL
make[2]: `/opt/rh7/postgresql/postgresql-7.1/src/pl'
make[3]: `/opt/rh7/postgresql/postgresql-7.1/src/pl/plpgsql'
make -C src all
make[4]: `/opt/rh7/postgresql/postgresql-7.1/src/pl
> Is there an easy way to read the WAL files generated by Postgres? I'm
> looking into writting a replication deamon for postgres and think that
> the WAL files are the best way to know what has happened to the db and
> what has to be replicated. I have a roughed out idea of how to code it
> up
Is there an easy way to read the WAL files generated by Postgres? I'm
looking into writting a replication deamon for postgres and think that
the WAL files are the best way to know what has happened to the db and
what has to be replicated. I have a roughed out idea of how to code it
up but the on
On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote:
> At 1:50 AM -0400 4/6/01, Tom Lane wrote:
...
> >What version of libreadline do you have installed, and how does it
> >declare completion_matches()?
>
> I have whatever is standard on NetBSD 1.5. I noticed that configure
> found a
my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
which therefore included latent support for ipv6. it wouldn't take a huge
amount of effort to bring this back, would it?
(the user below is using VARCHAR for his ip addresses for this reason.)
--- Forwarded Message
Paul A Vixie <[EMAIL PROTECTED]> writes:
> my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
> which therefore included latent support for ipv6. it wouldn't take a huge
> amount of effort to bring this back, would it?
AFAIK we never actually *had* IPV6 support in those
> AFAIK we never actually *had* IPV6 support in those datatypes, only
> stubs for it.
the inet_net_pton implementation that was brought in from BIND had its
IPv6 portions scrubbed. micro-over-optimization of the contributed
"bitncmp" caused the "ipv4 as int" assumption to reoccur. i'm going to
