473,387 Members | 1,942 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 software developers and data experts.

Missing OID rant

<rant>

Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.

Here's an example:

Create table t1 (f1 integer);
insert into t1 values (1);

CREATE OR REPLACE FUNCTION GetOne() RETURNS integer AS '
DECLARE
i integer;
BEGIN
select f1 into i from t1 limit 1;
return i;
END;
' LANGUAGE 'plpgsql';

select GetOne(); <-- WORKS OK

drop table t1;
Create table t1 (f1 integer);
insert into t1 values (1);

select GetOne(); <-- ERROR: relation with OID xxxxxx does not exist

Now I know why this is happening, but it is really crap.

Here's a solution (similar to what Oracle does (I believe):

Whenever you delete an object, you locate any functions (or other objects)
referencing that object's OID, and you mark them as invalid, and any
subsequent objects that now refer to the newly invalidated object(s).

When a function is invoked which is marked invalid, then it is first
parsed/compiled again - if that is successful then the function executes
as before. If compiling is unsuccessful, then the standard "relation with
OID xxxxxx does not exist" error could be returned (or perhaps an even
better error message detailing the actual name of the missing object, God
forbid!).

Where else would this be useful? How about the following scenario when you
want to make use of a temporary table in a pl/pgsql function:

-- This will not work
....
CREATE TEMP TABLE foo AS SELECT ....;
FOR r IN SELECT * FROM foo
LOOP
.....
END LOOP;
DROP TABLE foo;

-- You have to do this
....
CREATE TEMP TABLE foo AS SELECT ....;
FOR r IN EXECUTE "SELECT * FROM foo"
LOOP
.....
END LOOP;
DROP TABLE foo;
....

This might even make rebuilding databases easier because you could refer
to objects (during the rebuild) that don't yet exist (haven't been
inserted yet), but that would be validated the first time the object was
actually accessed.

There are loads of instances (db in flux, move table to another schema
etc) why you might want/need to drop a table, and recreate it. But in
Postgres, you have to reapply all DDL statements to the db that referenced
that dropped/recreated object - this is just not fun!

I don't know, but cannot believe that it would be hard to implement this,
and although many might not think that it is worth it, it is a really NICE
feature in Oracle. And when you're used to it, it is a royal pain in the
ass not having it.

</rant>

BTW, I still love postgres - I just want it to be better!

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #1
12 2000
Alvaro Herrera said:
Actually, in your example the only thing you need to do is close the
connection and reconnect. I agree it would be nice to recompile the
function automatically, but it's not as bad as you put it.


Thanks, I wasn't aware of that.

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #2
Alvaro Herrera said:
Actually, in your example the only thing you need to do is close the
connection and reconnect. I agree it would be nice to recompile the
function automatically, but it's not as bad as you put it.


Thanks, I wasn't aware of that.

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #3
Tom Lane said:
"John Sidney-Woollett" <jo****@wardbrook.com> writes:
Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.


Criticism in the form of a patch would be useful.


I know but I don't have the expertise to do that - I was only trying to
raise the issue... :)
Whenever you delete an object, you locate any functions (or other
objects)
referencing that object's OID, and you mark them as invalid, and any
subsequent objects that now refer to the newly invalidated object(s).


Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes


Is the query plan cached for the life of the session, or the life of the
cache/database/postmaster session?

Isn't removing the plan from the cache, and marking objects invalid two
separate although related issues?
I don't know, but cannot believe that it would be hard to implement
this,


Step right up ...


Believe you me, you don't want my code - it's been quite a few years since
I've done any C programming, a patch I produced might set Postgres back 5
years!!

BTW, I was only highlighting the issue because the missing OID message bit
me in the ass again today, and I didn't realise that it existed as an
outstanding todo item.

I guess that there are other missing features like exception handling and
nested transactions which are more important and need attention more
urgently...

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #4
Tom Lane said:
"John Sidney-Woollett" <jo****@wardbrook.com> writes:
Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.


Criticism in the form of a patch would be useful.


I know but I don't have the expertise to do that - I was only trying to
raise the issue... :)
Whenever you delete an object, you locate any functions (or other
objects)
referencing that object's OID, and you mark them as invalid, and any
subsequent objects that now refer to the newly invalidated object(s).


Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes


Is the query plan cached for the life of the session, or the life of the
cache/database/postmaster session?

Isn't removing the plan from the cache, and marking objects invalid two
separate although related issues?
I don't know, but cannot believe that it would be hard to implement
this,


Step right up ...


Believe you me, you don't want my code - it's been quite a few years since
I've done any C programming, a patch I produced might set Postgres back 5
years!!

BTW, I was only highlighting the issue because the missing OID message bit
me in the ass again today, and I didn't realise that it existed as an
outstanding todo item.

I guess that there are other missing features like exception handling and
nested transactions which are more important and need attention more
urgently...

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #5
On Thu, Apr 22, 2004 at 02:07:39PM +0100, John Sidney-Woollett wrote:
There are loads of instances (db in flux, move table to another schema
etc) why you might want/need to drop a table, and recreate it. But in
Postgres, you have to reapply all DDL statements to the db that referenced
that dropped/recreated object - this is just not fun!


Actually, in your example the only thing you need to do is close the
connection and reconnect. I agree it would be nice to recompile the
function automatically, but it's not as bad as you put it.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #6
On Thu, Apr 22, 2004 at 02:07:39PM +0100, John Sidney-Woollett wrote:
There are loads of instances (db in flux, move table to another schema
etc) why you might want/need to drop a table, and recreate it. But in
Postgres, you have to reapply all DDL statements to the db that referenced
that dropped/recreated object - this is just not fun!


Actually, in your example the only thing you need to do is close the
connection and reconnect. I agree it would be nice to recompile the
function automatically, but it's not as bad as you put it.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #7
"John Sidney-Woollett" <jo****@wardbrook.com> writes:
Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.
Criticism in the form of a patch would be useful.
Whenever you delete an object, you locate any functions (or other objects)
referencing that object's OID, and you mark them as invalid, and any
subsequent objects that now refer to the newly invalidated object(s).
Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes
I don't know, but cannot believe that it would be hard to implement this,


Step right up ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #8
"John Sidney-Woollett" <jo****@wardbrook.com> writes:
Please can someone explain why Postgres cannot recognize that objects
(referenced by pl/pgsql functions) whose OID no longer exists could in
fact be found (as new objects) if the function was reparsed and compiled
again.
Criticism in the form of a patch would be useful.
Whenever you delete an object, you locate any functions (or other objects)
referencing that object's OID, and you mark them as invalid, and any
subsequent objects that now refer to the newly invalidated object(s).
Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes
I don't know, but cannot believe that it would be hard to implement this,


Step right up ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #9
Jan Wieck said:
Exactly, and because of that we want you to do the easy stuff with the
cache invalidation, so that we have the time to think about the others.


Might be easy for you... I shudder when I try to imagine the size of the
mountain that that simple task would represent for me ;)

John Sidney-Woollett

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

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #10
Jan Wieck said:
Exactly, and because of that we want you to do the easy stuff with the
cache invalidation, so that we have the time to think about the others.


Might be easy for you... I shudder when I try to imagine the size of the
mountain that that simple task would represent for me ;)

John Sidney-Woollett

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

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #11
John Sidney-Woollett wrote:
Tom Lane said:
Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes


Is the query plan cached for the life of the session, or the life of the
cache/database/postmaster session?


DB connection is the lifetime of PL/pgSQL cached plans.

Isn't removing the plan from the cache, and marking objects invalid two
separate although related issues?
It is.
I don't know, but cannot believe that it would be hard to implement
this,
Step right up ...


Believe you me, you don't want my code - it's been quite a few years since
I've done any C programming, a patch I produced might set Postgres back 5
years!!


Well, that's what I do with French people, I convince them that it hurts
less if they rather talk English or German instead of me uttering
something in their language.

BTW, I was only highlighting the issue because the missing OID message bit
me in the ass again today, and I didn't realise that it existed as an
outstanding todo item.

I guess that there are other missing features like exception handling and
nested transactions which are more important and need attention more
urgently...
Exactly, and because of that we want you to do the easy stuff with the
cache invalidation, so that we have the time to think about the others.
Jan

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #12
John Sidney-Woollett wrote:
Tom Lane said:
Yup, this is on the TODO list, and has been for awhile:

* Flush cached query plans when their underlying catalog data changes


Is the query plan cached for the life of the session, or the life of the
cache/database/postmaster session?


DB connection is the lifetime of PL/pgSQL cached plans.

Isn't removing the plan from the cache, and marking objects invalid two
separate although related issues?
It is.
I don't know, but cannot believe that it would be hard to implement
this,
Step right up ...


Believe you me, you don't want my code - it's been quite a few years since
I've done any C programming, a patch I produced might set Postgres back 5
years!!


Well, that's what I do with French people, I convince them that it hurts
less if they rather talk English or German instead of me uttering
something in their language.

BTW, I was only highlighting the issue because the missing OID message bit
me in the ass again today, and I didn't realise that it existed as an
outstanding todo item.

I guess that there are other missing features like exception handling and
nested transactions which are more important and need attention more
urgently...
Exactly, and because of that we want you to do the easy stuff with the
cache invalidation, so that we have the time to think about the others.
Jan

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

17
by: Bart Nessux | last post by:
How can one view the contents of a queue? I'd like to verify that the queue has the same number of objects as the list that has been put into it. Also, should one think of a queue as static or...
0
by: Trevor Best | last post by:
<rant> Spent an hour yesterday figuring that one out in my sp, on an insert statement that used a join for the source. Even rebooted the server in desperation. It wasn't until I took that join and...
0
by: John Sidney-Woollett | last post by:
<rant> Please can someone explain why Postgres cannot recognize that objects (referenced by pl/pgsql functions) whose OID no longer exists could in fact be found (as new objects) if the function...
67
by: PC Datasheet | last post by:
Transaction data is given with date ranges: Beginning End 4/1/06 4/4/06 4/7/06 4/11/06 4/14/06 4/17/06 4/18/06 4/21/06 426/06 ...
8
by: Jamie | last post by:
Hello Newsgroup: This is my little rant about security and why we have home directories. You may choose to ignore it or disagree with it, that is your perogative and I won't care, but... this...
41
by: rick | last post by:
Why can't Python have a reverse() function/method like Ruby? Python: x = 'a_string' # Reverse the string print x Ruby: x = 'a_string' # Reverse the string
0
by: =?Utf-8?B?Z3V5?= | last post by:
<Rant> Why is it so hard to use a GridView? I have spent 2 weeks writing an app and it is fine. I have spent 1 week of this time trying to find out how to either a) set column widths for an...
60
by: DuncanIdaho | last post by:
Hello This is a rant. If you don't want to read it then don't, simple really. I usually spend my working life buried away in the back ends (fnar) of business systems. Serverside stuff over...
17
by: Christoph Zwerschke | last post by:
I'm just reading PEP 3107 (function annotations) and wonder why exceptions are not mentioned there. I think it would be helpful if one could specify which exceptions can be raised by a function,...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.