Re: [BUGS] BUG #8514: cache lookup failed for relation 421062806
On Thu, Oct 10, 2013 at 1:24 AM, shahtejas2...@gmail.com wrote: my postgresql running file . but sometime i found cache lookup failed for relation 421062806 error in postgresql log. can anyone tell me significant of this error. A relation has disappeared even if the session hold a sufficient lock on it, ensuring that the relation have to be present. -- Michael -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bit String expand bug
Gabriel Ciubotaru gciubot...@bitdefender.com writes: There's a problem with expanding Bit String data types, it make right padding with 0 instead of left padding , making the bit mask almost useless. You need to show an example of the problem; this report has no details that would let us fix anything. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8516: Calling VOLATILE from STABLE function
Terje Elde te...@elde.net writes: Would it be possible (and make sense) to solve this in a completely different way, not walking the function tree or doing static analysis, but simply setting and checking a bit during execution? While it's possible that we could do something like that, I think it's fairly unlikely that we would. The reason is that it would disable constructs that some people find useful; that is, sometimes it's intentional that a stable function calls a volatile one. A couple of examples: 1. You might want to make some database updates but continue to do queries with a pre-update snapshot. A single function can't accomplish that, but the combination of a stable outer function with a volatile update function can. 2. A security checking function (for use with Veil or the proposed row security feature) might wish to log accesses without denying them. To do that it'd have to be volatile, so if we had a restriction like this the function would fail when invoked within a stable function. You can imagine various ways around such issues, but it would add a lot of complication. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8518: FreeBSD usage in 9.3.1
The following bug has been logged on the website: Bug reference: 8518 Logged by: david Email address: david.ku...@vsoftcorp.com PostgreSQL version: 9.3.1 Operating system: Windows 7 Description: Hi All, I had tried using FreeBSD disk encryption but unable to find tool to encryption in Windows OS . can some one please help me in encrypting the disk. Thanks David jaya Kumar. K -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8516: Calling VOLATILE from STABLE function
According to the documentation, f() should be marked VOLATILE also, since calling f() produces side effects. PostgreSQL does not give a warning (or better yet, an error); I think it should. I think the answer is that function authors are required to prevent functions they mark as STABLE from calling VOLATILE functions. -- I understand it's an error (at least usually), my question/issue is why does PostgreSQL NOT give at least a warning when a programmer (probably accidentally) calls a VOLATILE function in one that he has specifically tagged as STABLE? The compiler has all the information to notify the programmer of a mistake, but isn't. This violates a fundamental principle of software engineering--take every opportunity to prevent errors. Dwayne -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Feature request - Information Schema enhancement
I know the Information Schema is a SQL standard, but it's somewhat lacking. I was trying to write a web page that showed a db table,it's columns and foreign keys. All went well and I was able to get this tool working great using the information_schema, problem is that some of the information_schema views only show items that you own (not that you have access to) and as a result, when I logged in as a DB user that didn't own some of the tables, the constraints wouldn't show up. I was able to work around this by creating my own information_schema view all_constraint_column_usage (using oracle's naming convention as inspiration) that met my need. The view did exactly what constraint_column_usage does, but I left off part one of the where predicates that enabled this restriction. Is this something that we'd ever consider implementing in information_schema, or is there a better place to do something like this? Using the PG tables may change from version to version so that's out, but it'd be nice to have views like the ones in information_schema that weren't OID based.
