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
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
> 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:
> >> 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
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
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
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
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
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
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
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
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.)
>
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
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
> 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
> 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
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
> > >
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
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
> 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
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
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
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.
--
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, 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
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
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
--
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
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
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
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 '
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) "
"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:
/*
"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.
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.
_
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
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
?
38 matches
Mail list logo
