Is the only way to create DB in a C code to connect
to Template1 and then exec the SQL string "CREATE DATABASE databasename"
?
Can I create DB without connecting to template1
?
Dear all :
help me please :
I compile my c++ program to connect Postgres Sql with command line :
c++ -I /usr/local/pgsql/include -L /usr/local/pgsql/lib -lecpg -lpq -g -o capek.cgi
capek.cc
and I ve got eror
" Segmentation fault (core dumped) "
could any body tell me what happen ..
Zudi
sometimes i'm getting:
NOTICE: Child itemid in update-chain marked as unused - can't
continue repair_frag
during a simple "vacuum", db is online.
pg version 7.1, on debian linux kernel 2.4.
what's the problem?
thanks,
valter m.
_
"Serguei Mokhov" <[EMAIL PROTECTED]> writes:
>> Hello Peter,
>>
>> There was a little typo in line 73 in the original file libpq.pot:
>>
>> #: fe-connect.c:713
>> #, c-format
>> msgid "could not socket to non-blocking mode: %s\n"
>>
>> missing the word 'set' between 'not' & 'socket'...
Yes.
"V. M." <[EMAIL PROTECTED]> writes:
> sometimes i'm getting:
> NOTICE: Child itemid in update-chain marked as unused - can't
> continue repair_frag
> during a simple "vacuum", db is online.
> pg version 7.1, on debian linux kernel 2.4.
> what's the problem?
The source code says:
/*
Given Hiroshi's objections, and the likelihood of compatibility problems
for existing applications, I am now thinking that it's not a good idea to
turn off OID generation by default. (At least not for 7.2 --- maybe in
some future release we could change the default.)
Based on the discussion so f
1. Just changed
TAS(lock) to pthread_mutex_trylock(lock)
S_LOCK(lock) to pthread_mutex_lock(lock)
S_UNLOCK(lock) to pthread_mutex_unlock(lock)
(and S_INIT_LOCK to share mutex-es between processes).
2. pgbench was initialized with scale 10.
SUN WS 10 (512Mb), Solaris 2.6
On Wed, 1 Aug 2001, Tom Lane wrote:
> Based on the discussion so far, here is an attempt to flesh out the
> details of what to do with OIDs for 7.2:
>
> 1. Add an optional clause "WITH OIDS" or "WITHOUT OIDS" to CREATE TABLE.
> The default behavior will be WITH OIDS.
>
> Note: there was some di
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> For input, I see no downside to just
>> ignoring the incoming OIDs. For output, I can see three reasonable
>> possibilities:
>>
>> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
>> "do the right thing", but a rather strong objection is
Tom Lane wrote:
>
> Given Hiroshi's objections, and the likelihood of compatibility problems
> for existing applications, I am now thinking that it's not a good idea to
> turn off OID generation by default. (At least not for 7.2 --- maybe in
> some future release we could change the default.)
>
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>
>> Given Hiroshi's objections, and the likelihood of compatibility problems
>> for existing applications, I am now thinking that it's not a good idea to
>> turn off OID generation by default.
> Would OIDs be globally unique or per ta
I recall seeing a message by Tom Lane stating that dropping and
re-creating a primary index may speed up db performance. Is there a
SQL command that will do this?
My current method is to use pg_dump -s to dump out the schema. Then I
go through and cut out everything but the CREATE INDEX lines. Th
Just off the top of my head,
Couldn't you write a little PL/PGSQL procedure which queries the system
tables and builds statements to execute with the new EXECUTE command for
each record returned that would drop and recreate the indexes? It would
take a little work but would be generic enough to a
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>
> >> Given Hiroshi's objections, and the likelihood of compatibility problems
> >> for existing applications, I am now thinking that it's not a good idea to
> >> turn off OID generation by default.
>
> > Would
mlw <[EMAIL PROTECTED]> writes:
> how hard would it be to have an OID range on a per
> table basis?
The existing OID generator is a system-wide counter, and couldn't
reasonably be expected to do something like that.
There was some talk of (in essence) eliminating the present OID
generator mechan
See REINDEX.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing l
Tom Lane wrote:
> See REINDEX.
>
Thanks.
-Tony
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[EMAIL PROTECTED] wrote:
>
> I noticed that pltcl didn't have any way to get to SPI_lastoid like plpgsql does.. I
>started using pltcl a lot because I like to decide when and how my queries get
>planned.. so I put one together really quick
>
Please note that OIDs may be optional in 7.2 though
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> For input, I see no downside to just
> >> ignoring the incoming OIDs. For output, I can see three reasonable
> >> possibilities:
> >>
> >> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
> >> "do the right thing", but a rather strong
> BTW, while digging through my mail archives I discovered that Oliver
> *did* already extract his "peer" auth patch and submit it as a proposed
> patch --- see the pghackers archives for 3-May-2001. At the time I
> think we were concerned about portability issues, but as long as it's
> appropria
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can someone find the Solaris patch submitted a few months ago that did a
> similar thing? I can't seem to find it.
I couldn't find one either. I found a couple of unsupported assertions
that Solaris and *BSD had SO_PEERCRED, so the Linux patch might w
Maybe I'm being horribly stupid here, but
If the thinking is that some tables can escape having an OID, thus meaning OIDs
can be controlled by table, how hard would it be to have an OID range on a per
table basis?
Where each table to have its own notion of an OID, then OID wrap/depletion
sho
Stephan Szabo wrote:
> The output from the select, should I believe be (3,1), (4,1)
> not (4,1), (4,1). I think we're violating General Rule 4 (I think
> that's it) on the referential constraint definition ("For every
> row of the referenced table, its matching rows, unique matching
> rows, and n
Is it possible to access tables in one database from another database if
they're in the same cluster? I dont seem to be able to do it; is there
something I have to do or is it impossible?
Ie.
If I have two databases accessible from the same postmaster; one called
db_one and the other called db_t
I have a function (plpgsql) and would like it to have access to the name
of the current database. Unfortunately, I dont know how to ask the
question.
I've look in the documentation, and I can get a list of possible
databases from pg_database, but I dont know which one I'm currently in.
dave
--
On Wed, 1 Aug 2001, Jan Wieck wrote:
> Stephan Szabo wrote:
> > The output from the select, should I believe be (3,1), (4,1)
> > not (4,1), (4,1). I think we're violating General Rule 4 (I think
> > that's it) on the referential constraint definition ("For every
> > row of the referenced table,
On Wed, 1 Aug 2001, Dave Blasby wrote:
> Is it possible to access tables in one database from another database if
> they're in the same cluster? I dont seem to be able to do it; is there
> something I have to do or is it impossible?
No, AFAIK, this isn't currently possible.
--
Attached is the patch you suggested, with a documentation addition. Is
this correct?
> I noticed that pltcl didn't have any way to get to SPI_lastoid like plpgsql does.. I
>started using pltcl a lot because I like to decide when and how my queries get
>planned.. so I put one together really q
Kindly format OIDs with %u not %d ... otherwise it looks reasonable...
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTEC
> Given Hiroshi's objections, and the likelihood of compatibility problems
> for existing applications, I am now thinking that it's not a good idea to
> turn off OID generation by default. (At least not for 7.2 --- maybe in
> some future release we could change the default.)
This seems good. Pe
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 6. COPY out WITH OIDS will ignore the "WITH OIDS" specification if the
>> table has no OIDs. (Alternative possibility: raise an error --- is that
>> better?) COPY in WITH OIDS will silently drop the incoming OID values.
> Obviously, the case here is
At 12:22 PM 8/1/01 -0700, Stephan Szabo wrote:
>On Wed, 1 Aug 2001, Dave Blasby wrote:
>
> > Is it possible to access tables in one database from another database if
> > they're in the same cluster? I dont seem to be able to do it; is there
> > something I have to do or is it impossible?
>
>No, A
On Wed, 1 Aug 2001, Naomi Walker wrote:
> At 12:22 PM 8/1/01 -0700, Stephan Szabo wrote:
> >On Wed, 1 Aug 2001, Dave Blasby wrote:
> >
> > > Is it possible to access tables in one database from another database if
> > > they're in the same cluster? I dont seem to be able to do it; is there
> > >
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> 6. COPY out WITH OIDS will ignore the "WITH OIDS" specification if the
> >> table has no OIDs. (Alternative possibility: raise an error --- is that
> >> better?) COPY in WITH OIDS will silently drop the incoming OID values.
>
> > Obviously, the c
> Kindly format OIDs with %u not %d ... otherwise it looks reasonable...
Change made.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your back
I am not sure if people noticed the signature lines, but the Toronto Red
Hat developers have started submitting patches based on TODO items.
Their involvement will help PostgreSQL improve even faster. Welcome
aboard folks.
--
Bruce Momjian| http://candle.pha.pa.us
On Wed, Aug 01, 2001 at 05:12:25PM +0700, Zudi Iswanto wrote:
> I compile my c++ program to connect Postgres Sql with command line :
> c++ -I /usr/local/pgsql/include -L /usr/local/pgsql/lib -lecpg -lpq -g -o capek.cgi
>capek.cc
>
> and I ve got eror
>
> " Segmentation fault (core dumped) "
While looking at what needs to be done with some
of the referential actions to make them work
better under deferred constraints, I noticed something
which I think is a bug.
sszabo=> create table base (a int unique);
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'base_a_key' for
table '
38 matches
Mail list logo
