Re: [GENERAL] C++ / pgsql Interface

1998-09-02 Thread Brook Milligan

   I have recently discovered the C++ interface and want to make use of it.

   2)  What --with  options will I need at compoile time to enable the C++
   Interface?  (--with-libs+DIRS, --with-includes=DIRS)

You shouldn't need any special configure options, unless the configure
script cannot find you c++ compiler (look in the configure output to
see how it responds to the c++ tests).  If it can't find a c++
compiler, use the --with-CXX=compiler option, where compiler is a path
to your c++ compiler.

To prevent compilation of the c++ interface, use the --without-CXX
option.

All this is in the INSTALL file in the root of the postgresql
distribution.

Cheers,
Brook



[GENERAL] primary key info

1999-06-25 Thread Brook Milligan

What information is kept in the system tables concerning primary keys?
How is it accessible?

Is there any means of specifying primary key information for views?

Cheers,
Brook



Re: [GENERAL] Can you write into a view?

1999-10-14 Thread Brook Milligan

   Hello, I'm a new into the postgres's world, and I was
   seeing the User's Guide from V.6.4 and I saw that you
   can write into a View. In the new versions can you? If
   not, have any body any idea of when it would be
   reality?

You can do so now.  Just create a ON INSERT rule for the view.  You
can also create ON DELETE and ON UPDATE rules.  As a result, views can
be made to respond just like tables.  See Jan's excellent description
in the docs on how to use rules.  I think he has all this covered,
including examples.

Cheers,
Brook





[GENERAL] cannot extend error

2000-03-09 Thread Brook Milligan

I am running some queries and receive the following message:

ERROR:  pg_noname.3635.3: cannot extend.  Check free disk space.

I am confused, because there seems to be plenty of disk space in the
partition containing the databases.  I have the binaries installed on
a different partition, but it also has a fair amount of space.

Is there any way to figure out what the problem is?  What partition is
it needing space in?  Is there a reason this message might appear that
has nothing to do with disk space?

Thanks for your help.

Cheers,
Brook



[GENERAL] NOTICE from vacuum

2000-05-08 Thread Brook Milligan

I am getting the following NOTICE from vacuum:

NOTICE:  Index tag_surveys_d_field_survey__key: NUMBER OF INDEX' TUPLES (6475) IS NOT 
THE SAME AS HEAP' (6474)

How does such a thing come about?  Do I just drop the index and remake
it?  Is the index or the heap correct?

Thanks for your help.

Cheers,
Brook



Re: [GENERAL] RE: [HACKERS] pg_dump & blobs - editable dump?

2000-07-12 Thread Brook Milligan

   If anyone can send me a nice interface for reading and writing a tar file
   from C, I'll do it. I just don't have the inclination to learn about tar
   internals at the moment. By 'nice' I mean that I would like:

I don't know the details of the API, but the NetBSD pax code handles
tar formats (and others) nicely and on a cursory glance seems to have
what you need.  Of course, the license is acceptable.  If you want the
source, let me know.

Cheers,
Brook



Re: [GENERAL] SQL scripts - sequences

2000-08-29 Thread Brook Milligan

   The problem I am encountering is with having a primary key labeled as
   serial.  Do I have to drop the sequence also to be able to recreate the
   table?  Omitting the sequence drop did not seem to allow the creation of the
   table with a serial, but when I added a drop sequence, the table creates
   fine in the script.  Am I assuming correctly?

Yes and yes.

   If that is correct, what if I go a step farther and have data dumped from
   the table before it is dropped.  Won't my sequence be screwed up if I drop
   it and then reimport the data?  Would the sequence technically be back at 1
   and if I have 100 records, will it try to insert duplicate data?

   If that is true, what would be the solution?  Create the sequence manually,
   don't drop the sequence in the script, and have the create table script not
   as a SERIAL, but have it set to a default value of the sequence?

My solution in a similar situation is to have a bunch of scripts to
drop/create the tables/functions/views/triggers/... needed.  Use
pg_dump to dump just the data (not the schema) but include the -c flag
(I use -a -c -D) so that sequences are dropped and recreated with the
right values.  To reload:  run pg_dump -a -c -D, run your scripts
(which drop and recreate the data structures, then run your pg_dump
output through psql to reload the data.  Sequences and tables will
agree fine.

Cheers,
Brook



Re: [GENERAL] image storing

2000-10-06 Thread Brook Milligan

   But I think that hyperlinks would be a good addition to data types
   repertoire to pgsql.

And how would the behavior of such a datatype differ from, for
example, a text datatype?  My interpretation would be that if the
consumer of the data wants to display it as a hyperlink, fine, but
that that is the job of the application not the database.  Am I
missing something?

Cheers,
Brook



[GENERAL] Re: [HACKERS] While we're on the subject of searches...

2001-04-28 Thread Brook Milligan

   Over the past few months there've been a number of requests for an
   interactive type documentation setup like the folks at php.net have.

Great to add to the documentation, but I hope the PostgreSQL project
doesn't take it so far as to make the primary documentation
interactive.  A well-thought out, coherent document is _much_ more
useful than the skads of random tips that characterize some other
projects.  The current document is very well-written (though perhaps
incomplete).  I would hate to see that decline in quality.

Cheers,
Brook

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [GENERAL] [ANNOUNCE] Great Bridge ceases operations

2001-09-14 Thread Brook Milligan

   Great Bridge .org, http://greatbridge.org/, will remain in place until
   projects are migrated to a new site.

Are there any plans to migrate things like the information on their
benchmarks against other databases?  Those are valuable pieces of
information in the broader PostgreSQL context and it would be a shame
to loose them.

Cheers,
Brook

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html