2013/3/29 tahoe-gary
> In what version of PG is the 'my_type'::regtype::oid syntax available? I
> want to introduce this to the JDBC driver which currently does the most
> ridiculous query that totally ignores search path.
>
> JDBC driver does this currently: SELECT oid FROM pg_catalog.pg_type
In what version of PG is the 'my_type'::regtype::oid syntax available? I
want to introduce this to the JDBC driver which currently does the most
ridiculous query that totally ignores search path.
JDBC driver does this currently: SELECT oid FROM pg_catalog.pg_type WHERE
typname = ?
So if you h
Actually, all I need is to:
SELECT oid::regtype, oid FROM pg_type WHERE ...
to make cache of OIDs.
2010/12/8 Dmitriy Igrishin
> Yeah, thank you very much!
>
> I've found it already too, but not post back!
>
> Thanks!
>
> 2010/12/8 Tom Lane
>
> Dmitriy Igrishin writes:
>> >> How can I get OID
Yeah, thank you very much!
I've found it already too, but not post back!
Thanks!
2010/12/8 Tom Lane
> Dmitriy Igrishin writes:
> >> How can I get OID by name rather than alias ?
>
> > SELECT oid FROM pg_type WHERE typtype = 'b' AND typarray <> 0 AND
> > typname::regtype = 'integer';
>
> Seems
Dmitriy Igrishin writes:
>> How can I get OID by name rather than alias ?
> SELECT oid FROM pg_type WHERE typtype = 'b' AND typarray <> 0 AND
> typname::regtype = 'integer';
Seems like the hard way --- if you think carefully about what regtype
is doing, you'll realize that this is incredibly ine
SELECT oid FROM pg_type WHERE typtype = 'b' AND typarray <> 0 AND
typname::regtype = 'integer';
Many thanks to Florian Pflug.
2010/12/8 Dmitriy Igrishin
> Hey general@,
>
> SELECT oid FROM pg_type WHERE typname = 'integer';
> oid
> -
> (0 rows)
>
> SELECT oid FROM pg_type WHERE typname = '
On Wed, Jun 16, 2010 at 10:42 PM, zhong ming wu wrote:
> Dear List
>
> Where can I find this mapping of oid to pg data types mentioned in
> libpq documentation?
> Why is such information not mentioned in the documentation? A general
> knowledge?
curious: what do you need the oids for?
built in
On Wednesday 16 June 2010 7:42:02 pm zhong ming wu wrote:
> Dear List
>
> Where can I find this mapping of oid to pg data types mentioned in
> libpq documentation?
> Why is such information not mentioned in the documentation? A general
> knowledge?
>
> Thanks
>
> Mr Wi
I think you are looking for
> > It is posible to access to the row OID of the row which fired a pl/perl
> > trigger?
>
> > If I try to access to $_TD->{new}{oid} or $_TD->{old}{oid} I have no
> > result.
>
> It looks to me like plperl_hash_from_tuple considers only user
> attributes. Not sure if this would be worth changin
Antonio =?ISO-8859-1?Q?Jos=E9_Garc=EDa?= Lagar writes:
> It is posible to access to the row OID of the row which fired a pl/perl
> trigger?
> If I try to access to $_TD->{new}{oid} or $_TD->{old}{oid} I have no
> result.
It looks to me like plperl_hash_from_tuple considers only user
attributes.
> There are basically two ways to attack the problem of a database-wide
> unique ID:
>
> * Use a single int8 sequence for the whole database;
>
> * Use the combination of table OID and row OID (or, perhaps, an int8
> sequence for the row identifier, if you need more than a billion or
> so rows in
"Kevin Field" <[EMAIL PROTECTED]> writes:
> Either way, are 64-bit OIDs planned within the next couple years?
No, they're not planned at all. That line of thought has pretty much
died off, to the point where OIDs in user tables are not just deprecated
but not there at all by default.
There are b
Hi everyone,
I just came across a thread in the pgsql archives from October 2000, and found
this post particularly interesting:
http://archives.postgresql.org/pgsql-sql/2000-10/msg00044.php
...because I had already been designing something similar but on a larger
scale, for an integrated infor
On Fri, Jun 09, 2006 at 04:27:41AM -0700, Bert wrote:
> Thanks, so it seems that i can delete the OIDs but not insert them okay
> so i have to recreate the table.
I think a better question would be: why are you using OIDs in the first
place? You'll almost certainly be much happier with a serial co
Thanks, so it seems that i can delete the OIDs but not insert them okay
so i have to recreate the table.
Terry Lee Tucker schrieb:
> On Friday 09 June 2006 06:34 am, "Bert" <[EMAIL PROTECTED]> thus
> communicated:
> --> Hi list
> --> What is the comment to add OIDs to a already existing table, or
On Friday 09 June 2006 06:34 am, "Bert" <[EMAIL PROTECTED]> thus
communicated:
--> Hi list
--> What is the comment to add OIDs to a already existing table, or i have
--> to recreate the table?
-->
--> Thanks,
--> Clemens
-->
-->
Well, according on \h ALTER TABLE on version 7.4.6 all you can do is
Thank you Tom for your concise response. Your explanation is very helpfull.
We were aware of the wraparound issues, but this has worked so well for us
that we haven't explored changing it yet. Having a unique identifier per row
is most usefull in our situation and we didn't think we were anyw
Chris Kratz <[EMAIL PROTECTED]> writes:
> We aren't sure at this point if the problem we are having has to do with the
> fact that we drop and reload the test db quite often and so we are running
> into OID wraparound, or if it has to do with the fact that we recently went
> to 8.1 on this test
On Thu, Apr 28, 2005 at 08:51:50PM -0600, Michael Fuhr wrote:
>
> I'm not aware of a way to get the current function's OID in PL/pgSQL,
> but you can do it in C.
Yeah, i know that...I was hoping it would be possible from pl/pgsql :-(
> Why do you need to know the function's schema? What are you
On Thu, Apr 28, 2005 at 10:37:47PM +0200, Matko Andjelinic wrote:
>
> Is there a way to know the OID of the current plpgsql function from
> inside the function?
I'm not aware of a way to get the current function's OID in PL/pgSQL,
but you can do it in C.
> What I really need is to extract the nam
Thanks, Neil.
Hubert Fröhlich wrote:
Those days, we had PostgreSQL 7.1 and 7.2, and we had to be careful
oids approaching 2^32 (2.14 billion)
Now, we have 8.0. What does the situation look like?
With the default settings, there is exactly the same risk of OID
wraparound as in earlier releases.
Hubert Fröhlich wrote:
Those days, we had PostgreSQL 7.1 and 7.2, and we had to be careful oids
approaching 2^32 (2.14 billion)
Now, we have 8.0. What does the situation look like?
With the default settings, there is exactly the same risk of OID
wraparound as in earlier releases. However, you ca
On Tue, 26 Apr 2005 07:24 pm, Hubert Fröhlich wrote:
> Hi list,
>
> some time ago, there was a discussion about oid wraparound. See
> http://archives.postgresql.org/pgsql-general/2002-10/msg00561.php .
>
> Those days, we had PostgreSQL 7.1 and 7.2, and we had to be careful
> oids approaching 2^
Martijn van Oosterhout wrote:
Not quite, a single index entry needs to point to any number of rows,
which may or may not be visible depending on your transaction, so they
form a sort of linked list. But indeed, not terribly useful for your
purpose...
This make's sense, I keep forgetting the vers
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Which reminds me that you wanted to make VACUUM FULL do the equivalent
> of a REINDEX instead of retail deletion of index entries ... is that
> still the idea? Would it do that always, or only under certain
> conditions?
It's still on the to-do list.
Alvaro Herrera wrote:
> On Sat, Jan 15, 2005 at 04:21:24PM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > Out of curiosity, what clears out the old index tuples? Vacuum?
> >
> > Right.
>
> Which reminds me that you wanted to make VACUUM FULL do the equivalent
> of a R
On Sat, Jan 15, 2005 at 04:21:24PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Out of curiosity, what clears out the old index tuples? Vacuum?
>
> Right.
Which reminds me that you wanted to make VACUUM FULL do the equivalent
of a REINDEX instead of retail deletion of i
On Sat, Jan 15, 2005 at 04:00:19PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sat, Jan 15, 2005 at 07:10:48PM +0100, Bo Lorentsen wrote:
> >> Hmm, so a data row update also update the CTID in all indexes, too. I=20
> >> see what you mean !
>
> > Not quite, a single index entry
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Out of curiosity, what clears out the old index tuples? Vacuum?
Right.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http:/
Martijn van Oosterhout writes:
> On Sat, Jan 15, 2005 at 07:10:48PM +0100, Bo Lorentsen wrote:
>> Hmm, so a data row update also update the CTID in all indexes, too. I=20
>> see what you mean !
> Not quite, a single index entry needs to point to any number of rows,
> which may or may not be visib
On Sat, Jan 15, 2005 at 07:10:48PM +0100, Bo Lorentsen wrote:
> >Using the CTID, which locates the physical tuple as (block,num). When
> >you update a tuple, or vacuum moves it its CTID will change, so it's
> >not terribly useful from a user's point of view.
> >
> Hmm, so a data row update also upd
Uh, sorry, my mistake !
I had put SERIAL instead of an INTEGER in the table definition !
You just removed a bug in my schema ;)
On Sat, Jan 15, 2005 at 09:02:12AM +0100, PFC wrote:
As a sidenote, I have a table with a primary key which is not a
sequence, and this query displa
Martijn van Oosterhout wrote:
But where in the documentation did you see anything saying that they
were unique? I imagine you just inferred that from somewhere. I'm not
sure where the documentation should be changed since nowhere actually
recommends them in any way.
Hmm, how about as a comment n
On Sat, Jan 15, 2005 at 05:53:08PM +0100, Bo Lorentsen wrote:
> Michael Fuhr wrote:
>
> >The view assumes single-column primary keys defined as SERIAL types.
> >
> is this the "c2.relkind = 'S'" in the view ?
That restricts the view to show only dependent objects that are
sequences ('S'). Defini
On Sat, Jan 15, 2005 at 05:53:08PM +0100, Bo Lorentsen wrote:
> Michael Fuhr wrote:
> >The view assumes single-column primary keys defined as SERIAL types.
>
> is this the "c2.relkind = 'S'" in the view ?
No, that means the pg_class entry is a sequence.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"
PFC wrote:
As a sidenote, I have a table with a primary key which is not a
sequence, and this query displays the non-existing sequence name. It
would be easy to check if the sequence exists (yet another join !),
only display sequences that exist ;)...
Hmm, I just tried the same, and got a
On Sat, Jan 15, 2005 at 05:11:16PM +0100, Bo Lorentsen wrote:
> Alvaro Herrera wrote:
> >Most system catalogs use OIDs as primary keys. So they cannot just
> >disappear. But on user tables, there's not a lot of use for them IMHO.
> >
> Ok, I think it is about time it is stated more clearly in the
Michael Fuhr wrote:
Here's a first attempt at a view that shows tables and their primary
key columns and sequences. I chose a view instead of a function
because a view shows everything in the database with a single query,
which simplifies visual examination of the results. Modify it or
convert it
Alvaro Herrera wrote:
Most system catalogs use OIDs as primary keys. So they cannot just
disappear. But on user tables, there's not a lot of use for them IMHO.
Ok, I think it is about time it is stated more clearly in the documentation.
There's no internal row id on Postgres; having one would
On Sat, Jan 15, 2005 at 09:02:12AM +0100, PFC wrote:
>
> As a sidenote, I have a table with a primary key which is not a
> sequence, and this query displays the non-existing sequence name. It
> would
> be easy to check if the sequence exists (yet another join !), only display
> se
I've done only trivial testing, so if anybody finds a situation
where the view fails (taking the above assumption into account)
then please describe it.
Nice !
As a sidenote, I have a table with a primary key which is not a sequence,
and this query displays the non-existing sequence name. It w
On Fri, Jan 14, 2005 at 06:39:25PM -0600, Jim C. Nasby wrote:
>
> If you do manage to write a function that will do this I hope you can
> share it with the community. IMHO PostgreSQL could do with more
> functions for querying the system catalogs.
Here's a first attempt at a view that shows table
On Fri, Jan 14, 2005 at 05:10:10PM -0300, Alvaro Herrera wrote:
> On Fri, Jan 14, 2005 at 12:20:50PM -0700, Michael Fuhr wrote:
> > On Fri, Jan 14, 2005 at 07:44:18PM +0100, Bo Lorentsen wrote:
> > > Alvaro Herrera wrote:
> > >
> > > >You can create a function to get the sequence name attached to
It's not very hard to do. I just got rid them. It took me about a day. Our
application is an X-Windows front end written is C. I wrote a function to
return the next value of the serial key for any table. Here is the select
statement buitl with sprintf:
"SELECT relname FROM pg_class WHERE relkind
On Sat, Jan 15, 2005 at 12:06:41AM +0100, Bo Lorentsen wrote:
> Ok, Tom told me about the same :-( But why are oid's still in PG, that
> are they good for ? Will there be a real unique row id, like there is in
> Oracle, or will this be keept as an internal value only ?
Most system catalogs use
On Sat, Jan 15, 2005 at 12:06:41AM +0100, Bo Lorentsen wrote:
> Martijn van Oosterhout wrote:
> >It means using OIDs as you described has very well known problems and
> >they will break on you eventually. You can mitigate the damage by
> >creating a UNIQUE index on the oid column but you'd better b
Michael Fuhr wrote:
See the "System Catalogs" chapter in the documentation.
Ok, I think I will compile all the given information in this thread, to
make a new and more non oid'ish solution, as the dataset I manage are
going to grow quite a lot :-)
If you run "psql -E" you'll see the queries t
Alvaro Herrera wrote:
Yeah, though things get hairy that way because you have to peek at
pg_attribute to match the objsubid in pg_depend; and self-join pg_class
to get to the index itself. Not sure if it all can be done in a single
query.
Sounds like my task, to make an oid free insert/select,
Michael Fuhr wrote:
The PostgreSQL documentation discourages the use of OIDs for primary
keys. For example, the "Object Identifier Types" section in the
"Data Types" chapter says:
...
Thanks for taking you the time to snip this together, I think I will try
to find a way to find the propper pri
Martijn van Oosterhout wrote:
It means using OIDs as you described has very well known problems and
they will break on you eventually. You can mitigate the damage by
creating a UNIQUE index on the oid column but you'd better be sure your
application can handle the side-effects.
Ok, Tom told me a
On Fri, Jan 14, 2005 at 12:20:50PM -0700, Michael Fuhr wrote:
> On Fri, Jan 14, 2005 at 07:44:18PM +0100, Bo Lorentsen wrote:
> > Alvaro Herrera wrote:
> >
> > >You can create a function to get the sequence name attached to a table.
> > >Of course, you should take into account the fact that there
On Fri, Jan 14, 2005 at 07:44:18PM +0100, Bo Lorentsen wrote:
> Alvaro Herrera wrote:
>
> >You can create a function to get the sequence name attached to a table.
> >Of course, you should take into account the fact that there could be
> >more than one (two serial fields in a table are rare but not
On Fri, Jan 14, 2005 at 07:39:16PM +0100, Bo Lorentsen wrote:
> But, does this mean that the oid sollution I have decriped (and
> implimentet) have some unknown problems, or will oid's become obsolete
> in the near future ?
It means using OIDs as you described has very well known problems and
th
On Fri, Jan 14, 2005 at 07:39:16PM +0100, Bo Lorentsen wrote:
>
> But, does this mean that the oid sollution I have decriped (and
> implimentet) have some unknown problems, or will oid's become obsolete
> in the near future ?
The PostgreSQL documentation discourages the use of OIDs for primary
Tom Lane wrote:
The thing you have to worry about is the possibility of duplicate OIDs
once your DB has been running long enough for the OID counter to wrap
around (2^32 OIDs). You should make sure that index is specifically
declared as UNIQUE, so that any attempt to insert a duplicate OID will
fa
Alvaro Herrera wrote:
You can create a function to get the sequence name attached to a table.
Of course, you should take into account the fact that there could be
more than one (two serial fields in a table are rare but not
impossible), but if your tables have only one sequence you should be OK.
Michael Fuhr wrote:
You could query the system catalogs for the table's primary key,
either on the client side or in a server-side function. The
pg_attrdef table even has the default value's nextval() expression
with the sequence name, which could be converted into a currval()
call.
This is not
On Fri, Jan 14, 2005 at 11:47:25AM +0100, Bo Lorentsen wrote:
> Michael Fuhr wrote:
>
> >PostgreSQL 8.0 will have a pg_get_serial_sequence() function that
> >returns the sequence name for a particular column so you don't have
> >to construct it. This is useful when a table or column has been
> >r
Bo Lorentsen <[EMAIL PROTECTED]> writes:
> I use normal tabel ID (SERIAL and BIGSERIAL) all over the place for FK
> constaints, but I use OID in one special situation. When I insert a
> single row into a table, I like my low level code to be kompatible with
> mysql ( mysql_insert_id ), and fetch
On Fri, Jan 14, 2005 at 11:39:54AM +0100, Bo Lorentsen wrote:
> Thanks, but this demands you to have the table and id_column name in
> your hand, and I don't right now.
You can create a function to get the sequence name attached to a table.
Of course, you should take into account the fact that t
Michael Fuhr wrote:
PostgreSQL 8.0 will have a pg_get_serial_sequence() function that
returns the sequence name for a particular column so you don't have
to construct it. This is useful when a table or column has been
renamed, in which case the above will probably break.
Quite nice but not what
Christian Kratzer wrote:
why should your application not want to know about the metadata of it's
own tables ? That sounds quite strange when you think about it.
Well, the ideer is to be compatible with mysql at the same level in the
code. This works nicely, as I have descriped, but I am concerned
On Fri, Jan 14, 2005 at 10:32:18AM +0100, Christian Kratzer wrote:
> $query = sprintf("SELECT currval('%s_%s_seq') AS
> id",$this->table,$this->id_column);
PostgreSQL 8.0 will have a pg_get_serial_sequence() function that
returns the sequence name for a particular column so you don't have
to con
Hi,
On Fri, 14 Jan 2005, Bo Lorentsen wrote:
Michael Glaesemann wrote:
You can use currval() to get the sequence value that was pulled from your
insert. You can check the documentation for usage, as well as searching
the archives for discussions of using OIDs as part of your database logic.
I kno
Michael Glaesemann wrote:
You can use currval() to get the sequence value that was pulled from
your insert. You can check the documentation for usage, as well as
searching the archives for discussions of using OIDs as part of your
database logic.
I know this, but i like not to know anything abou
On Jan 14, 2005, at 16:03, Bo Lorentsen wrote:
Now, are there any danger in using this method ? And if there is, how
can I do this trick without knowing the layout of the table I insert
into ?
You can use currval() to get the sequence value that was pulled from
your insert. You can check the doc
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What I find somewhat interesting is every other database I've used that
> exposes some kind of 'object ID' has a set of functions to map between
> an object name and it's ID, and vice-versa.
regression=# create function myfunc(int) returns int as 'selec
On Wed, Jan 12, 2005 at 04:08:28PM +0100, Thomas Hallgren wrote:
> Jim C. Nasby wrote:
> >Is there an easy way to get the OID of the currently running function?
> >(IE: the function you're in when you execute the code to see what
> >function you're in, if that makes any sense).
>
> In what languag
Jim C. Nasby wrote:
Is there an easy way to get the OID of the currently running function?
(IE: the function you're in when you execute the code to see what
function you're in, if that makes any sense).
In what language? In C you can use:
Datum your_function(PG_FUNCTION_ARGS)
{
Oid funcOid
"Katsaros Kwn/nos" <[EMAIL PROTECTED]> writes:
> Given the Oid restype of a Resdom "object", is there any system table I
> could query in order to retrieve the text representation of this type?
If you're talking about C code inside the backend, format_type_be() is
the usual subroutine.
On 22 Nov 2004 14:25:26 +0200, Katsaros Kwn/nos <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Given the Oid restype of a Resdom "object", is there any system table I
> could query in order to retrieve the text representation of this type?
>
> If for example a Resdom restype is 23 how can I get the string
Firstly, please don't send email in only HTML, it tends to get them
marked as spam.
> SPAM: Hit! (3.2 points) HTML-only mail, with no text version
Anyway, as to your question:
> Im planning on using OID for referencing in certain part of the
> system i am building as in this case using normal p
On Thu, 2004-11-11 at 14:34 -0500, Tom Lane wrote:
> Geoffrey <[EMAIL PROTECTED]> writes:
> > Do I get more oids on a 64 bit machine?
>
> No.
Nor will OIDs ever be 64 bit, I'd hazard to guess.
In any case using OIDs in applications is a bad idea -- you probably
should not be using them at all, l
Many thanks to all who have responded. I hope to be as helpful to the list
someday as each of you have been. Thanks...
On Thursday 11 November 2004 10:04 am, Terry Lee Tucker saith:
> Greetings,
>
> Here is a simple question:
>
> Is it ok to put a unique index on the oid for my tables? We are in
Geoffrey <[EMAIL PROTECTED]> writes:
> Do I get more oids on a 64 bit machine?
No.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Terry Lee Tucker wrote:
Greetings,
Here is a simple question:
Is it ok to put a unique index on the oid for my tables? We are in the process
of moving from Progress Software to PostgreSQL. In the Progress world, you
can always uniquely, and quickly find a record by using their version of oid,
wh
On Thu, Nov 11, 2004 at 10:04:30 -0500,
Terry Lee Tucker <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> Here is a simple question:
>
> Is it ok to put a unique index on the oid for my tables? We are in the
> process
Yes, but you may occasionally have insert failures if the oid wraps around
and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 11 November 2004 07:04 am, Terry Lee Tucker wrote:
> Greetings,
>
> Here is a simple question:
>
> Is it ok to put a unique index on the oid for my tables? We are in the
> process of moving from Progress Software to PostgreSQL. In the Progr
On Thu, 11 Nov 2004, Terry Lee Tucker wrote:
> Is it ok to put a unique index on the oid for my tables? We are in the process
> of moving from Progress Software to PostgreSQL. In the Progress world, you
> can always uniquely, and quickly find a record by using their version of oid,
> which is reci
"Ed L." <[EMAIL PROTECTED]> writes:
> ... with no corresponding entry that I can find in pg_class with
> that oid (I thought they were all in there).
Look at relfilenode, not OID.
regards, tom lane
---(end of broadcast)---
A better solution is to use the serial data type. OID is depreciated
and may go away.
http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-SERIAL
On 19 Oct 2004 07:54:36 -0700, Raffaele Spizzuoco
<[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm from Italy, and sorry about my english...
> I
Richard Huxton írta:
On Thursday 08 April 2004 15:21, Sky wrote:
Problem:
pg_loopen() unable to open PostgreSQL large object in...
Solution from another mailing list:
My blob oid was very big.
I had to cast to (float) the oid parameter of pg_loopen.
Sorry, bigger than what? Why float?
W
On Thursday 08 April 2004 15:21, Sky wrote:
> Problem:
> pg_loopen() unable to open PostgreSQL large object in...
>
> Solution from another mailing list:
> My blob oid was very big.
> I had to cast to (float) the oid parameter of pg_loopen.
Sorry, bigger than what? Why float?
> Question:
> The oi
Patrick Hess <[EMAIL PROTECTED]> writes:
> The only problem I have is related to this OID stuff -- I read a bit
> about this and found a way to solve my initial problems by creating my
> tables with "WITHOUT OIDS" -- works fine and CMS runs like on the
> original plattform (even faster but that'
On Thu, 19 Apr 2001, Toomas Gavrilin wrote:
> Sorry if my question sounds stupid, but ...
> Is there any way to get rid of postgres automatic generation of
> system attribute column 'oid'? The problem is, that we've used for years
> in our system tables attribute called oid (could be described a
Toomas Gavrilin writes:
> Is there any way to get rid of postgres automatic generation of
> system attribute column 'oid'?
No.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 1: subscribe
Jonas Bengtsson wrote:
>
> Can't you do a dump with the oid's?
>
> But when I want to know the primary key of the inserted row
> I have to do an extra select query. If I use oid I just use
> pg_getlastoid() in php.
> And it is redundant data to store another integer.
>
> Comments?
I have often
On Thu, 22 Mar 2001, Jonas Bengtsson wrote:
> Hello,
> I have problems with using OID as PK. I have created a
> UNIQUE INDEX on the oid on a relation called CourseEvents.
> The relation that is supposed to have a FK to CourseEvents
> is CourseEventsForums and it has a field called ceid which
Title: RE: Re: [GENERAL] OID as Primary Key
Isn’t is better to use nextval(). If there are many simultaneous
users vurrval might give the value of another insert.
/Jonas B
-Original
Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Title: RE: Re: [GENERAL] OID as Primary Key
And you can get the last SERIAL inserted using currval.
MikeA
>> -Original Message-
>> From: Brent R. Matzelle [mailto:[EMAIL PROTECTED]]
>> Sent: 22 March 2001 16:36
>> To: [EMAIL PROTECTED]
>> Sub
--- Jonas Bengtsson <[EMAIL PROTECTED]> wrote:
> Can't you do a dump with the oid's?
Yes, but I would never suggest it.
> But when I want to know the primary key of the inserted row
> I have to do an extra select query. If I use oid I just use
> pg_getlastoid() in php.
> And it is redundant d
Can't you do a dump with the oid's?
But when I want to know the primary key of the inserted row
I have to do an extra select query. If I use oid I just use
pg_getlastoid() in php.
And it is redundant data to store another integer.
Comments?
/Jonas B
> Jonas Bengtsson <[EMAIL PROTECTED]> wri
Jonas Bengtsson <[EMAIL PROTECTED]> writes:
> I have problems with using OID as PK.
This strikes me as a fairly bad idea in any case. What happens if you
must dump and reload your database? Better to use a SERIAL column as
primary key.
regards, tom lane
---
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What about pre-fetching of OID's. Does that still happen for every
> > backend?
>
> Only ones that actually allocate some OIDs, I think.
>
> > What about XID's?
>
> XIDs are wasted on a postmaster restart, but not per-backend, because
> they are
On Wed, Oct 18, 2000 at 06:18:07PM +0200, Peter Eisentraut wrote:
> > - Any other limitation I don't achieve to view?.
>
> Nope, this is really a relatively standard thing. The oid column isn't
> special as compared to other columns, aside from the fact that it is
> automatically created.
DaVinci writes:
> Can I use OIDs for joins between tables without losing functionality?
Sure.
> The problems I am afraid of are:
>
> - pg_dump/psql: Can I recover OIDs from security copies?.
pg_dump -o
> - Indexes: joins between tables linked with OIDs use indexes from
>
surfer girl wrote:
>
> The documentation on this is so scarse it's hard to figure out what the right format
>is supposed to be for all this. After much searching (websites, various mailing list
>archives), I found the "note" that PHP has a special variable "userfile" for file
>uploads.
It has
The documentation on this is so scarse it's hard to figure out what the right format
is supposed to be for all this. After much searching (websites, various mailing list
archives), I found the "note" that PHP has a special variable "userfile" for file
uploads. This I have changed, and a straigh
On Tue, May 02, 2000 at 10:13:14PM -0800, surfer girl wrote:
> --- "Robert B. Easter" <[EMAIL PROTECTED]> wrote:
> >
> >Try recompiling php 4.0RC1 or whatever is current with the latest Apache
> >source (1.3.12). I'm thinking maybe you are not running php as compiled into
> >the server.
>
> Tha
--- "Robert B. Easter" <[EMAIL PROTECTED]> wrote:
>
>Try recompiling php 4.0RC1 or whatever is current with the latest Apache
>source (1.3.12). I'm thinking maybe you are not running php as compiled into
>the server.
Thanks - I had PHP compiled into the server - though I may try the recompile a
1 - 100 of 113 matches
Mail list logo
