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
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
. So I'm inclined to think
this scenario is a don't do that.
Having said that, though, it seems like a bad idea to be calling
set_pglocale_pgservice() before palloc is functional. It's not at all
obvious that that function can't be allowed to use palloc.
regards, tom lane
find it in a desultory search.)
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
*will* drive this
function to stack overrun, if you don't run out of heap memory first
(I think the heap consumption will be O(N^2) ...). Consider rewriting
it with a loop rather than recursion.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
in LIKE patterns ...
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
kind of background maintenance
task that wasn't there before?
You might try enabling query logging (log_statement = all) to see exactly
what's happening at the time you get one of these errors.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
. The thing this theory doesn't explain is why would Terje be
having trouble reproducing the failure? Seems like re-running the same
query ought to produce the same failure.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
Andres Freund and...@2ndquadrant.com writes:
Terje, do you use read committed or repeatable read/serializable?
Or even more to the point, can you apply the just-posted patch and see
if the problem goes away for you?
regards, tom lane
--
Sent via pgsql-bugs mailing
.
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
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
Not sure. It's pretty disturbing that this wasn't caught earlier;
it seems to me that means there's no regression coverage that hits
ExecReScanMergeAppend. However, I don't much like this specific test
--- pushed.
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
, it would not push down the WHERE clause in either
this example or the stackoverflow one, because it could/would change the
results.
Or in short, this isn't a bug, but a counterexample to the stackoverflow
discussion.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
that and the
declaration of the constant that's tickling the bug.
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
for USE_PPC_LWARX_MUTEX_HINT in pg_config_manual.h).
We do have a configure-time check for that, but maybe it's not working
for him?
Without any info as to the compiler or assembler in use, nor a look at the
failing bits of assembly code, we're just guessing.
regards, tom lane
--
Sent via
you are seeing.
Hmm ... identifier case-folding isn't really supposed to do anything to
multibyte characters. I wonder if this isn't a variant of the issue
recently fixed in commit d535136b5d60b19f7ffa777b97ed301739c15a9d.
regards, tom lane
--
Sent via pgsql-bugs mailing
, if we change pg_stat_statements so it doesn't
break out SQL-language functions, I'm sure somebody's gonna complain.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
-spec syntactic sugar). To say nothing of existing
applications that may be relying on calling the underlying functions with
their existing argument order.
The inconsistency in argument order is unfortunate but we're long since
stuck with it, I'm afraid.
regards, tom lane
could produce unexpected results
--- and in this case, unexpected result probably means security
failure.
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
is preventing
those rows from getting vacuumed away. Perhaps you have a prepared
transaction lying around?
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
to close these xa transactions without
restarting the whole db?
Just use ROLLBACK PREPARED with the ID you see in pg_prepared_xacts.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
think?
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
a darn about
a 15-year-old version of HPUX, but if you can reproduce the above
on your Windows machine, I'd suggest filing a bug about it with them.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
the justify_days(),
justify_hours(), and justify_interval() functions.
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
dependency in the behavior of strtod(). I don't think
we can promise to hide all such dependencies, but maybe it'd be a good
idea to take care of this particular one.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
but the wording of the spec clearly requires +Infinity as well as the
forms with just inf. (It also appears to require +/- NaN to be
accepted, but I have no idea what that would mean and suspect it to
be a thinko.)
Barring objections I'll go make this change.
regards, tom lane
/shortcoming rather than claim it's our problem.
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
' purview. It's barely
possible that the Postgres JDBC driver has something to do with that,
but it sounds more like the XA manager's turf.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Tom Jenkinson tom.jenkin...@redhat.com writes:
On Mon 29 Jul 2013 15:46:12 BST, Tom Lane wrote:
No idea, but in any case that's outside Postgres' purview. It's barely
possible that the Postgres JDBC driver has something to do with that,
but it sounds more like the XA manager's turf.
I am
that there were order
dependencies on some platforms.
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
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-25 09:48:31 -0400, Tom Lane wrote:
The proposed patch seems a bit overcomplicated --- isn't the real
problem that I changed the ordering of the header probes in
be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized
them
on an OpenBSD build that code wouldn't be used anyway (not even
when talking to a pre-9.1 server, if I'm interpreting the comment
correctly).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-25 11:50:47 -0400, Tom Lane wrote:
So on an OpenBSD build that code wouldn't be used anyway (not even
when talking to a pre-9.1 server, if I'm interpreting the comment
correctly).
As far as I understood it, it wouldn't be used as long
. ARRAY[1] @ NULL yields NULL. NOT (NULL) is still
NULL. WHERE treats a NULL result as FALSE.
It might help you to consider that NULL means unknown. It does not
mean empty array.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
there :-(
Suggested fix at:
https://gist.github.com/RhodiumToad/5901567
Seems reasonable, will fix.
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
joinaliasvars lists can only contain Vars or COALESCE expressions :-(.
Will fix.
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
that (if you have privileges), but it's up to you to keep it
in sync with the extension definition file.
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
Jeff Frost j...@pgexperts.com writes:
On Jul 18, 2013, at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I see no bug here. This is not different from any other
property-alteration you might do on an extension member object.
We allow that (if you have privileges), but it's up to you to keep
.
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
belongs to which
query.
I suspect there are some other infelicities in pg_stat_statements'
behavior for multi-query strings, too. At least for now, that
combination is best avoided.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
=841c9b6ba151ed5a41733ec345bf9bf32a55f4dc
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
DDL. I can't get
particularly excited about this one compared to the rest. We could try
to extend the table-locking protocols to apply to all object types ...
but from here, the amount of work and complexity involved seems far out
of proportion to the benefit.
regards, tom
.
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
with configure's
speed problem.
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
Peter Eisentraut pete...@gmx.net writes:
On 7/1/13 9:19 AM, Tom Lane wrote:
AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need
: ## ##
that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
that in this case --- it doesn't
look like there's enough info in the dump to tell where the dependency
link should have led. But we should think about it a little before
taking the easy way out.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
That's operating as designed.
The table-part in the sequence name was truncated.
Would you rather it failed entirely? You're up against the limit on
name length (63 bytes in a standard Postgres build).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-27 10:29:14 -0400, Tom Lane wrote:
Your proposed patch will only fix the problem for dumps created after
it ships. In the past, we've tried to deal with this type of issue by
having pg_restore fix up the dependencies when reading a dump
: [ the right thing ]
Applied with minor cosmetic changes.
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
.
But if we can identify specific call sites that seem at more risk than
most, I'm okay with adding extra logic there.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
?
The given error message is definitely complaining about being unable to
write a pg_xlog file --- stats or other temp files are not relevant.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Jeff Davis pg...@j-davis.com writes:
On Tue, 2013-06-25 at 09:46 -0400, Tom Lane wrote:
That's definitely telling you it got ENOSPC from a write in
$PGDATA/pg_xlog.
Either that, or write() wrote less than expected but did not set errno.
Good point. I wonder if he's using a filesystem
filesystem
anyway. Do you find that panfs works all right for Postgres other than
this issue?
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
saner. (Delete the one database that you're able to get rid of
first.)
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
:-(
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
you're
working in.
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
have a lot of control over order of evaluation of subexpressions.
So it seems we need to stop processing after finding a single WHEN
that's not const?
That's not an acceptable fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Hiroshi Inoue in...@tpf.co.jp writes:
OK I made a test C program which reproduces the crash.
The program uses libpq and a hack.
Oh, thank you, I was just about to go spend an hour doing that ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
uses libpq and a hack.
I've committed a fix for this. Thanks again for the test case.
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
, 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
thought out, but it's
really not regexp_matches()'s fault that you're running into this
problem --- rather, it's the fact that one arm of the CASE can return a
set while the other can't.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
, perhaps because the SIGHUP signals the
postmaster should be sending them are getting lost. I'm not sure how we
might track down the cause though. How various are the platforms
you're seeing this on?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Jeff Frost j...@pgexperts.com writes:
On Jun 13, 2013, at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... So one theory about this would be that those processes
aren't absorbing the GUC updates, perhaps because the SIGHUP signals the
postmaster should be sending them are getting lost
fail to rotate if it
gets ENFILE while trying to open the new log file. That doesn't look
like it'd explain the lack of log_checkpoint activity, though. Also,
usually people notice this state because everything else on the box
starts to fall over ...
regards, tom lane
g...@antrez.pl writes:
Is it ok that we loose referential integrity by locking DELETE on table
test_item ?
Yes. If you put a trigger on a table involved in an FK constraint, it's
your responsibility that the trigger doesn't break FK update operations.
regards, tom lane
(or severe enough)
fixes have accumulated since the last time. Historically we've averaged
about four minor releases a year, but that's not set in stone anywhere.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
to, say, getTableAttrs. OTOH, if that makes the normal
dump-everything case noticeably slower, it's unlikely such a patch would
get accepted.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
query. We ought to fix that.
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
.
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
for the report!
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
-30-2012'::date;
^
HINT: Perhaps you need a different datestyle setting.
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
to tell whether there's such a constraint in your case ...
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
-createindex.html
points this out both in the syntax diagram and the text.
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
, and having it
return an additional flag array that says this output column is unsafe
to reference in quals at all.
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
documented as
returning a palloc'd array, and why the heck do we have a long comment
about its implementation in LogStandbySnapshot?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think the proposed fix is fine code-wise; the real problem here is
crummy commenting. GetRunningTransactionLocks isn't documented as
returning a palloc'd array, and why the heck do we have a long comment
about
those are all operating as intended.
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
arbitrary decisions. We've made them that way, and it
would take a pretty impressive argument to persuade us to break existing
applications by changing them.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
during refactoring to have all the ALTER .. RENAME operations go
through the same code paths.
Are we sure the documentation's not wrong? A quick test says this
syntax isn't accepted in *any* existing release, and I can't say I
understand what it should do anyway.
regards, tom
Simon Riggs si...@2ndquadrant.com writes:
On 26 May 2013 17:10, Tom Lane t...@sss.pgh.pa.us wrote:
More readable would be to invent an intermediate nonterminal falling
between ColId and ColLabel, whose expansion would be IDENT |
unreserved_keyword | col_name_keyword | type_func_name_keyword
, but there are some places where we can see either ColId_or_Sconst
or DEFAULT. I don't know of any sane way to express all reserved
keywords except DEFAULT to bison, so the best we can realistically do
is to accept all not-fully-reserved keywords in these places.
regards, tom lane
, the check will always fail when the product has more than 8
fractional digits. It's not Postgres' place to decide that that wasn't
what you wanted to happen.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
it to be
used as input:
http://www.postgresql.org/docs/9.2/static/datetime-config-files.html
Or perhaps better, use the ISO datestyle to eliminate the whole issue of
timezone abbreviations.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
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
schemas, you'd probably need
\df *.sp_get_league_prediction
to see both.
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
this code with FDDEBUG
set, has anyone else?
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
with that.
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
, and the contrived test case below
reproduces the issue.
I've repeated the test below on a 9.1.9 installation, and it works fine there.
Given the reference to EvalPlanQual in your stack trace, I'm thinking
the explanation is this 9.0 fix:
Author: Tom Lane t...@sss.pgh.pa.us
Branch: master
Todd A. Cook tc...@blackducksoftware.com writes:
On 05/15/13 16:10, Tom Lane wrote:
Given the reference to EvalPlanQual in your stack trace, I'm thinking
the explanation is this 9.0 fix:
Thanks for the explanation. Is there any chance of that fix being backpatched
into 8.4?
None whatsoever
.
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
new(f1,new) to stdout;
1 2
You sure the server is 9.1?
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
into ModifyTable plan nodes. Anyway, I doubt
we'd consider changing trigger behavior in 8.4.x at this late date.
You should update to a newer release series if this is a problem for you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
this right.
The attached patch fixes it.
This is another case where I'm not too sure if we ought to back-patch.
The current behavior is clearly wrong, but perhaps some application
out there will be unhappy if we change it in back branches?
regards, tom lane
diff --git
wedded to using '0001-01-01 00:00:00+01', you
might consider building yourself a custom timezone database that has
an entry defined the way you want. But personally I'd recommend
changing to something less randomly chosen.
regards, tom lane
--
Sent via pgsql-bugs mailing
format specifier being able to match '.' regardless of
locale. Perhaps we should only apply this to HEAD and not back-patch?
regards, tom lane
diff --git a/src/backend/utils/adt/formatting.c b/src/backend/utils/adt/formatting.c
index db5dfca51d477d3e9b33b8d2c264495b3b2ec433
one scankey refers to the same consistentFn, ie, the
same index column. A bit surprising we've not seen this before,
because I think that code has been like that for awhile.
Will fix, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
.
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
case, col = 1 is still NULL, but id 20 is FALSE,
so you have NULL AND FALSE which is FALSE (*not* NULL), and so failure
is per spec.
Yes, the behavior of AND/OR with NULLs is documented.
http://www.postgresql.org/docs/9.1/static/functions-logical.html
regards, tom lane
. I don't see that suppressing the strerror result would add
anything much.
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
1 - 100 of 6572 matches
Mail list logo
