[BUGS] Error in returning setof records
Hi all, when i am returning function as setof record then it will give error "ERROR: set-valued function called in context that cannot accept a set CONTEXT: PL/pgSQL function "gfs_ls" while casting return value to function's return type" plz help me to get rid of it -- With Regards, Anjali Arora Project Engineer Hardware Technology And Development Group Center for Development of Advanced Computing Pune University Campus,Ganeshkhind Pune-411007 Tel: 020-25704320 Mob: 09372441025 Web: www.cdac.in ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
On 25-apr-2006, at 16:46, Tom Lane wrote: Paul van der Zwan <[EMAIL PROTECTED]> writes: AFAIK getpagesizes() appeared in 2001 so that probably means it is missing in anything before Solaris 9. We could handle this without relying on getpagesizes() by just trying and falling back: #ifdef SHM_SHARE_MMU memAddress = shmat(shmid, addr, SHM_SHARE_MMU); if (memAddress == (void *) -1 && errno == EINVAL) memAddress = shmat(shmid, addr, 0); #else memAddress = shmat(shmid, addr, 0); #endif That would be a clean solution ( and was suggested by some of my colleagues as well) However, I would argue that a system is pretty broken if it exposes the SHM_SHARE_MMU #define and then rejects it at runtime. It is just a define, the fact that this define exists has nothing to do with it having any meaning. It's not like a HAVE_ISM flag. shmat() can fail for a number of reasons, one of them is not having ISM available on the current system. I'll see if I can get the x86 experts here to have a look at it... I think either Solaris/x86 should not expose this #define, or it should silently ignore the bit at runtime. AFAICS, SHM_SHARE_MMU has no guaranteed semantic effect anyway, it's just a performance hint; so ignoring it on platforms that can't handle it is reasonable. I disagree, I have no definite info why it is a hard failure, probably because there is no way to communicate to the app that it's request is ignored. System calls either fail or succeed. And introducing a new errno value just for this is overkill, I guess. regards, tom lane Regards Paul ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
On 25-apr-2006, at 20:34, Tom Lane wrote: Paul van der Zwan <[EMAIL PROTECTED]> writes: On 25-apr-2006, at 16:46, Tom Lane wrote: AFAICS, SHM_SHARE_MMU has no guaranteed semantic effect anyway, it's just a performance hint; so ignoring it on platforms that can't handle it is reasonable. I disagree, I have no definite info why it is a hard failure, probably because there is no way to communicate to the app that it's request is ignored. Which applications do you think will do anything except exactly what you are proposing we do, ie, just redo the call without the flag bit? Why are you going to make every application jump through this hoop in order to cope with a (possibly temporary) inadequacy in some seldom-used versions of Solaris? We'll probably put in the kluge because we have no other choice, but I strongly disagree that it's our problem. I think I have to make something clear, I am not part of the Solaris Engineering group and even though I work for Sun I personally have probably less influence on Solaris than a customer. What I wrote/write is my personal opinion and I should insert the usual disclaimer about me not 'officially' representing Sun Microsystems . I personally do believe that silently failing or ignoring something an application asks for explicitely is bad, if the application wants it and does not get it, the OS should communicate this to the application. I feel it is up to the application and not to the OS to decide how to respond when the request fails. It may be true that all or most applications will just redo it, or they may do something else because ISM is not present, to be honest I do not know. The code you suggested is IMHO a clean way to ask for an optimization and gracefully accept the denial and continue without it. My guess is the absence of ISM on the VIA cpu is purely a hardware issue and not related to a 'seldom used version of Solaris' as there are no different versions of Solaris, only different releases. If the hardware does not support something it may be difficult or impossible for an OS to implement a feature. It would be nice though if every CPU supports the large pages so the failure would never happen. Regards Paul ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Error in returning setof records
Anjali Arora wrote: Hi all, when i am returning function as setof record then it will give error "ERROR: set-valued function called in context that cannot accept a set CONTEXT: PL/pgSQL function "gfs_ls" while casting return value to function's return type" This is not a bug - see the manuals for details. A set returning function is like a table so you need to call it as: SELECT * FROM my_set_function(); For general help you might like to try the general/sql mailing lists rather than the bug tracker. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
