g 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 p
s 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
t, even if we fixed the CWD issue. 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
efer to?
(I think there was some discussion of this in the pgsql-hackers list
about a year ago, but I couldn't 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
nshtein(null, 'foobar')
> I get a ERROR: stack depth limit exceeded
Worksforme. You sure you transcribed the function accurately?
Note however that sufficiently long input strings *will* drive this
function to stack overrun, if you don't run out of heap memory first
(I think the hea
bles --- perhaps you added some 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
icious there's a
LIKE test coded as LIKE 'pg_%', which is wrong because "_" is a
metacharacter 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
point --- 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
Andres Freund 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
hitting the bug could depend on what series of
random values you get.
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 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 list (pgsql-b
report. 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
s isn't smart enough to do that
--- and even if it were, 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.
he
result column type, and it's the discrepancy between 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
mutex hints
(see the comment 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
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
ctions? At least, 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/pgsql-bugs
tactic 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 lan
conf.d-like directory 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://ww
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://www.pos
ing
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
dalone example --- Jeff, what do
you 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
the
other. If you want that sort of conversion, see 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
e "", line 1, in
ValueError: invalid literal for float(): inf
Now, I seriously doubt that the Python guys will give 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.
cases:
NaN
Infinity
-Infinity
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 obje
HPUX box; and you're complaining about Windows. So what we've got here
is a platform 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.
y 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.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
Tom Jenkinson 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 manag
x their
bug/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
"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 l
Andres Freund 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 woul
by libc).
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).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Andres Freund 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 alphab
, not realizing 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
of brain fade 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
ts 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
Jeff Frost writes:
> On Jul 18, 2013, at 11:47 AM, Tom Lane 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 it
>
e allow 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
op the connection.
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
t's what's going to happen, because there is no infrastructure
for determining which portion of the source text string 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
=commitdiff;h=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
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
tached is an updated patch for HEAD, with regression tests. This
> should also be applied to the 9.3beta branch.
Applied with minor adjustments --- mainly, I took out the inFromCl
twiddling, which AFAICS is neither necessary (nothing downstream of this
looks at inFromCl) nor clearly correct
Peter Eisentraut 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? IO
ile
and not two, then +1 for updating. Should help a bit 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
## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ##
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
g ]
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
Andres Freund 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 rea
equence:
> CREATE SEQUENCE
> t2345678901234567890123456789012345678901234567890_t1234_id_seq
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, t
way to do 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 lis
ery single write() call.
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/pgsql-bugs
Jeff Davis 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
?
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://
> length 1392640: No space left on device
That's definitely telling you it got ENOSPC from a write in
$PGDATA/pg_xlog. Maybe you have a user-specific space quota affecting
the postgres account?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bu
t CIFS couldn't be considered a supported 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
to a PANIC so we could get a stack
trace :-(
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
M FULL pg_database" makes things
any 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
er, it's the fault of whatever client-side software 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
on't
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
ill silently 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 ...
Jeff Frost writes:
> On Jun 13, 2013, at 4:50 PM, Tom Lane 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.
> Inte
processes
aren't absorbing the GUC updates, 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?
rega
7;t that well 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 l
urn-a-set statically instead of believing the first execution
result, but that might add an unpleasant amount of startup overhead.
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
gt; The program 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
Hiroshi Inoue 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@postgresql.o
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.
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
triction to getting RETURNING
results back from only the primary 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
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:
h
this patch
some and committed it. Thanks 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
is no "json_has_field" test function, nor any nice way to
build one from the provided functions.
It's probably too late to address this for 9.3, but we ought to put it
on the to-do list for 9.4.
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
te/time field value out of range: "10-30-2012"
LINE 1: select '10-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
d enough
info 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
fined, it's not
implemented).
Shouldn't be too hard to fix though. I'm thinking of moving most of the
detection logic for this into subquery_is_pushdown_safe, and having it
return an additional flag array that says "this output column is unsafe
to reference in quals at all&q
org/docs/9.2/static/sql-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
Stephen Frost 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 h
tRunningTransactionLocks isn't 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
ous of the details above, but in the end
they are all 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 maili
0001"
I believe 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
Simon Riggs writes:
> On 26 May 2013 17:10, Tom Lane 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_key
rammar for it was
> broken 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
erminal?
BTW, I tried just replacing ColId with ColLabel here, and that *almost*
works, 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 real
k( product = (val1 * val2)::numeric(23,8) )
Otherwise, 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 l
; this failing?
You need to add WIT to the timezone abbreviation list to allow 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.
reg
YTEA-OUTPUT
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
s "\df
> sp_get_league_prediction" return?
If they are in different 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
wrong 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
_foo_updates AS ON UPDATE TO foo DO NOTIFY foo;
> \d foo
Thanks, 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
stuff out entirely --- I've sure never built 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
"Todd A. Cook" 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.
our in production, 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
oved trigger processing 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 (p
#x27;2');
INSERT 0 1
regression=# copy 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
y locales can you point to where neither
the decimal point nor thousands_sep is "."? It certainly wouldn't be
enough to noticeably reduce the potential pain from this change, so
I decided that it'd be better to keep the behavior straightforward
and as-documented.
eTableFunctionResult appear to
get 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?
d though about whether
this might break any existing applications that are (incorrectly)
depending on a D 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
the timezone definition says.
If you're inextricably 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.
ry, the rank() function
does see them.
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
not work
if more than 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-bug
1 - 100 of 7582 matches
Mail list logo
