1. The PERL framework is only caching the insert and does not actually perform it until commit is issued.
2. You really are not on the same transaction even though it appears you are and the transaction isolation is such that you cannot see the insert until it is fully committed.
One possibility is that the INSERT is going to a different table (having the same name but existing in a different schema) that is visible/default to the function but not outside of it.
Or the function on the server is not "current" and thus isn't doing what you think it is.
> I do an insert via a function, which returns the new id, then later I try > to SELECT on that id, and it doesn't find it. > > Could it be because the insert is done inside a function?
Not by itself; but that factor could be interacting with something else to cause the observed behavior. As noted above functions are able to maintain their own "schema" environment so what is executed in one and outside of one can indeed target different physical objects - which has nothing to do with transaction visibility.
Susan Cassidy-3 wrote
> It is a fairly large and complex Perl program, so no, not really.
Then you need to recreate a functionally similar, but limited, test case that either exhibits the behavior in question or causes you to realize what you are doing in wrong in the "large and complex Perl program".
