In a postgres C function (CREATE FUNCTION LANGUAGE C), is it possible to get
the OID of a parameter and therefore overload a C function? Is there any other
way of overloading a C function?
Thanks
James
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
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 = '
Hey general@,
SELECT oid FROM pg_type WHERE typname = 'integer';
oid
-
(0 rows)
SELECT oid FROM pg_type WHERE typname = 'int4';
oid
-
23
(1 row)
How can I get OID by name rather than alias ?
--
// Dmitriy.
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
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
> > 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.
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.
Thanks in advance!
--
Antonio José García Lagar
Compact Software International SA
http://www.c17.net
--
Sent via pgsql-general mailing
Hi all,
I am using Postgresql 8.2.
I am using client side api to upload/download files to/from postgresql using
calls lo_export()/lo_import();
If I download a file from postgresql - few weeks later, files object's
contents got damaged.
I don't know why?
Do any of you have encountered same prob
> 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
Hi list
What is the comment to add OIDs to a already existing table, or i have
to recreate the table?
Thanks,
Clemens
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
Hello all,
We have a live server running on PG 8.0.3 which we backup on a regular bases
by doing a pg_dumpall --oids. We have a test server currently running 8.1.1
where we reload that dumpall using psql.
Now we have a history tracking system in the db which via triggers and rules
keeps track
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
Is there a way to know the OID of the current plpgsql function from
inside the function?
What I really need is to extract the name of the schema where the
function is stored.
--
matko
---(end of broadcast)---
TIP 5: Have you checked our extensive
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^
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^32 (2.14 billion)
Now, we have 8.0. What does the situation look li
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
Hi ...
I am using postgresql 7.4 on a pontencial large DB system, and I am
quite happy of the performance of this database, as for now. Only one
thing worrys me, and I like to get some pease to my mind about this.
I use normal tabel ID (SERIAL and BIGSERIAL) all over the place for FK
constaints
"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
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).
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.dist
"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
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 "integer"
or something like that? Are these mappings stored anyware?
Thanks in advance
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
Hi,
Im planning on using OID for referencing in certain part of the system
i am building as in this case using normal pk -> fk would be
inefficient as i have to have once table reference multi tables, but i
have concerns that if a Database is exported and reconstructed the
OID's will change ma
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
At 03:34 PM 11/11/04, Geoffrey wrote:
Bruno Wolff III wrote:
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 in
On Thu, Nov 11, 2004 at 15:34:14 -0500,
Geoffrey <[EMAIL PROTECTED]> wrote:
>
> "Whenever an application makes use of OIDs to identify specific rows of
> a table, it is recommended to create a unique constraint on the oid
> column of that table, to ensure that OIDs in the table will indeed
>
On Thu, Nov 11, 2004 at 03:34:14PM -0500, Geoffrey wrote:
> So this prompts a question regarding the documentation. I'm assuming
> that I can address the wrap-around issue based on the following found
> under "Notes" section of the "Create Table" document:
>
> "Whenever an application makes use
Bruno Wolff III wrote:
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
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]
Do I get more oids on a 64 bit machine? That is, is it also an unsigned
four-byte integer on a 64 bit machine?
--
Until later, Geoffrey
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nom
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
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,
which is recid. I remem
"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)---
While dealing with filesystem bloat issues, I found a large file
named 43710738, recently updated and sitting in one of my
database directories,
$ ls -lh ../../../data/base/11259315/43710738
-rw---1 dba dba 1016M Nov 3 17:05
../../../data/base/11259315/43710738
... with no
1 - 100 of 146 matches
Mail list logo
