nextval(), and each call of nextval() returns a different value.
One way to think about it is that a rule doesn't save any values away in
variables. Functions do save the arguments as variables on the stack,
and those variables can be used multiple times, so that's why calling a
function
I'm
not really sure what the behavior is supposed to be, but the output
shouldn't depend on the optimizer.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, 2008-08-25 at 22:26 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > => select max(a), generate_series(1,2) as g from foo order by g desc;
> > ERROR: set-valued function called in context that cannot accept a set
>
> This strikes me as
to do with the ORDER BY, so that part of my
example was unnecessary.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
than a UNION ALL
view.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
in 8.4 more
apparent?
Regards,
Jeff Davis
i = 1
print "set search_path = mytest, public;"
print "drop table if exists foo;"
print "create table foo (i int unique);"
while 1:
print "INSERT INTO foo select generate_series(%d, %d);" % (i, i + 9)
On Mon, 2008-10-06 at 11:10 +0300, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > I am seeing index bloat in the current head when the indexed values are
> > constantly increasing, and the lower values are being constantly
> > deleted.
> >
> > ...
> > I
On Tue, 2008-10-07 at 11:04 +0300, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > I see this problem on 8.3.3 now, too. Originally, I suppose my test was
> > not long enough, but now I see the problem after about 10 minutes of
> > running.
>
> I ran the script for a
On Tue, 2008-10-07 at 08:14 -0700, Jeff Davis wrote:
> In the VACUUM VERBOSE output I included, you can see that the heap is
> only 785 pages (after 200M rows went through that table), and it
> maintains that consistently. That means to me that the VACUUMs are
> running and properly
This does not look right to me:
=# select regexp_split_to_array('dsf,sdfsdf',',')::text[][100];
regexp_split_to_array
---
{dsf,sdfsdf}
(1 row)
Is this known?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
violation of the SQL standard. I've been wrong about the
SQL standard plenty of times though, so don't take my word for it ;)
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote:
> The only way to avoid this would be to lock before the sort, which could
> have the effect of locking more rows than are returned (if you also use
> LIMIT);
How would that work in the case of an index scan sort?
Regards,
J
schema paths as well, if it's not in some expected place (I think it
does so for all schemas other than pg_catalog).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
a-qualify it".
Have you considered working from the "custom" format rather than text?
I'm not sure whether it solves your problem, but I think it provides the
most information.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
(x tsvector, y pg_catalog.tsvector) RETURNS integer
LANGUAGE sql
AS $$ select 1; $$;
It seems like pg_dump tries fairly hard to make the output readable in
the typical case. It does seem a little inconsistent that the list of
types that make up another type don't follow the exact same
PE mytype2 AS (
j mytype
);
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
NT or SIGTERM to the backend.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
l.org/docs/8.3/static/server-shutdown.html
If you have an open COPY and no data is moving, it simply won't
terminate it. You can terminate it with ctrl-C from psql, but not a
SIGINT to the postmaster or a SIGINT or SIGTERM to the backend.
Regards,
Jeff Davis
--
Sent via pgsql-bugs m
That's perfectly acceptable to me. I'm only concerned about the shutdown
case, and that's the only case that's in conflict with the docs.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mmandRead protect us in the SIGINT case?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
SIGINT to a
backend. And in the case of SIGTERM to a backend, the connection will be
terminated anyway.
Regards,
Jeff Davis
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index c8223bf..c0d3622 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/cop
s us in a state so unsafe that we can't even abort the
transaction nicely.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
g/docs/8.4/static/sql-select.html#SQL-DISTINCT
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
but the start point of a
synchronized scan is stored in shared memory; otherwise, it wouldn't
know where to stop.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
> On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> > We could probably fix this specific issue by refactoring things in such
> > a way that the seqscan start point is frozen on the first read and
> > re-used after rewin
the same readfile() function in initdb.c. I
assume it's not a practical problem there, but it should be fixed.
Thanks to Corry Haines (chaines at truviso dot com) for reporting the
problem.
Regards,
Jeff Davis
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index
hose desirable behaviors unless you are
somehow aware that "'January 01, 2009'" is something more malleable than
"now()" in example #2. Calling the RHS "unknown" in example #2 gives us
that information.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2009-09-01 at 22:01 -0400, Tom Lane wrote:
> Huh, interesting corner case. I'd be inclined to fix by initializing
> maxlength to 1 though.
>
> Where's the memory leak?
The xstrdup() on the zero-length string.
Regards,
Jeff Davis
--
Sent via pgsql-bu
rals; but I disagree that using implicit casts to make up for a lack
of an "unknown" type will improve matters (either for convenience or
safety).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2009-09-04 at 11:15 -0400, Tom Lane wrote:
> On the whole, throwing an error seems better from a usability
> perspective.
>
> Comments?
Agreed.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
If I create a gist index over a box and a circle, the index attributes
appear to both have type box.
I don't see any other, similar situations with other types, and I
haven't investigated the cause yet. Most similar situations work fine.
Regards,
Jeff Davis
postgres=# sele
On Wed, 2009-09-16 at 10:36 -0400, Tom Lane wrote:
> This is expected, no? Those opclasses use the STORAGE option.
I see, that makes sense. I was making the assumption that the types
matched in my new patch, and obviously that's incorrect.
Regards,
Jeff Davis
--
Sent via pg
nd here:
http://www.postgresql.org/docs/8.4/static/datatype-xml.html
http://www.postgresql.org/docs/8.4/static/functions-xml.html
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
> Was this ever addressed?
>
It doesn't appear to be fixed, and I don't see it on the TODO, either.
Should we add it there?
Regards,
r the config we used."
I was trying to sort this bug out somewhat before posting, but we
weren't able to reproduce it (it happened near the end of testing, and
people were leaving), and I didn't have much chance to investigate in
the last week.
Regards,
Jeff Davis
postg...@
I looked at the TODO before sending this, and found
nothing regarding listen/unlisten.
I was unable to find the bug report sumission page at
www.postgresql.org, even though it was mentioned in
this template.
Your name : Jeff Davis
Your email address : [EMAIL
this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jeff Davis
Your email address : [EMAIL PROTECTED]
System Configuration
-
Ar
e interpretation of other
postgresql.conf settings?
What if you have a path set for archive_command and then you change the
standard_conforming_strings GUC and SIGHUP the server? Will the path be
incorrect?
Regards,
Jeff Davis
---(end of broadcast)--
riggering query
occurred within a function: the trigger is invoked before the function
proceeds to its next operation. For example, if a function inserts a new
row into a table, any nondeferred foreign key checks occur before
proceeding with the function."
Regards,
Jeff Davis
Ste
ls up. Or maybe we can somehow avoid needing to record the
relnodes to be deleted in order for the abort to succeed.
I'm still not sure why foreign keys on large insert statements don't eat
memory on 7.4, but do on 8.0+.
Regards,
Jeff Davis
---(e
On Wed, 2006-10-25 at 16:20 -0300, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > I found the root cause of the bug I reported at:
> >
> > http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
> >
> > What happens is this:
> > * Out of memor
On Wed, 2006-10-25 at 18:15 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Jeff Davis wrote:
> >> * smgrGetPendingDeletes() calls palloc()
> >> * palloc() fails, resulting in ERROR, causing infinite recursion
>
> > Hmm, mayb
se /some/file contains invalid UTF8 sequences, even
though it's the same file you copied out.
It seems to be essentially a data corruption issue if applications
insert binary data in text fields using escape sequences. Shouldn't
PostgreSQL reject an invalid UTF8 sequence in any
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
> It seems to be essentially a data corruption issue if applications
> insert binary data in text fields using escape sequences. Shouldn't
> PostgreSQL reject an invalid UTF8 sequence in any text type?
>
Another note: P
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
> You can insert invalid UTF8 bytes sequences into a TEXT type on an 8.1
> installation by doing something like:
>
I created a patch that appears to fix the problem, and does not appear
to break anything else.
Is this acceptable?
On Tue, 2006-10-31 at 16:13 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I created a patch that appears to fix the problem, and does not appear
> > to break anything else.
>
> ... except maybe bytea ...
>
Ok. So then it seems that the only po
On Tue, 2006-10-31 at 23:18 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Is this not a bug?
>
> I don't actually see that it is. The documentation is perfectly clear
> on the point:
>
> (It is your responsibility that the byte seq
rd. On 8.2 this returns 10. It appears to
be applying the filter too soon, and then it does an outer join which
violates the WHERE.
Regards,
Jeff Davis
test=> SELECT version();
I am sending this email on behalf of Russel Smith. He discovered this
bug and his description follows:
Verified on 8.2.3 on Fedora Core 6
Verified on 8.1.3 on RHEL4, custom compile. (I can't control the update to
8.1.8)
The output of an empty role name would possibly not be a problem, but when
the
ALTER TABLE ... OWNER TO syntax, which properly honors -O.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Wed, 2007-04-25 at 11:36 -0700, Jeff Davis wrote:
> pg_dump -O apparently removes all instances of ALTER TABLE ... OWNER TO
> from the output, but does not remove ALTER SEQUENCE ... OWNED BY from
> the output.
>
> Specifically this is with SERIAL sequences, which are dumped us
On Wed, 2007-04-25 at 16:44 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > pg_dump -O apparently removes all instances of ALTER TABLE ... OWNER TO
> > from the output, but does not remove ALTER SEQUENCE ... OWNED BY from
> > the output.
>
?
>
We could handle it essentially like a volatile set-returning function.
It may be easy to shoot oneself in the foot, but that is true for many
uses of volatile functions.
If the argument is that we shouldn't make it any easier, that's a fair
point, but this is one possible definit
On Tue, 2007-05-29 at 22:41 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote:
> >> It has the same problem that SELECT triggers have. How many rows should you
> >> expect that subquery to
':3"
This has the same result on beta1 and beta2.
I'm using en_US.UTF-8 on FreeBSD.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
t; (a PostgreSQL user) for tracking this bug
down.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
l works just fine now, and
that TCP is explicitly designed to prevent these kinds of problems, and
we only see this problem because FreeBSD 6.1 TCP is broken.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
ny return value at all (and thus do
not retransmit the message). I agree that is a problem (assuming I
understand what's going on).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appro
the results are. If
that is faster, the planner is not choosing the right plan. Try ANALYZE
to update the statistics, and if that doesn't work, post EXPLAIN
results.
Also, this post is somewhat off-topic for -bugs, try posting to -general
or -performance with this type of question.
Regards,
_data call
PageInit() if it's a new page. Are there other areas where a similar
problem might exist?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote:
> I think the simple fix would be to have copy_relation_data call
> PageInit() if it's a new page.
On second thought, why are PageSetLSN and PageSetTLI being called from
log_newpage(), anyway? It says that all of the callers use sm
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote:
> I was investigating some strange page corruption today in which the page
> was completely zeroed except for the LSN and TLI.
>
I see that this was added to the 9.0 open items list, but it affects
versions 8.3 and later.
I sh
g-point value, and then reload it, it may be
different than the one you started with. That can cause a problem with
either UNIQUE or EXCLUDE constraints.
If you are not using floating point values, please try to make a
self-contained test case that includes data that can reproduce the
problem.
R
t4)) =
(1::numeric + 1e-7::numeric)::float4;
?column?
--
f
(1 row)
> My own WAG is that we're talking about a GiST bug that causes it to
> recognize or not recognize duplicates depending on order of insertion.
> But that's theorizing far in advance of the data.
Seems
On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
> >> That's really *not* supposed to happen, assuming that both machines have
> >> IEEE float arithmetic and competently written float
On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> >> You need extra_float_digits cranked up. Which pg_dump knows about.
>
> > I can't reproduce the problem with float4/8, but I still
a feature
to make the optimizer smarter.
The optimizer will never be so good that it always picks the best path.
Consider a 100-table join: would it be a "bug" if it didn't find the
perfect join order?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
can't be planned this way, there are particular properties of MAX that
allow the optimization:
1. MAX(x) can be rewritten as: ORDER BY x DESC LIMIT 1
2. The MAX of set S is the MAX of the MAXes of each partition of S
The optimizer knows about the former, but not the latter.
Regards,
hackers
is better for problems without an obvious solution, where discussion is
required.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ecause I wasn't sure if it's safe to do that
before DisableCatchupInterrupt().
Regards,
Jeff Davis
[1] http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg00225.html
Note: I couldn't even find that in our email archive, but thanks to our
new git repo, I
nestly, and openly; even though it seemed like the
most trivial bug that I could imagine at the time.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
x is ROW(1,NULL),
then the former will evaluate to TRUE, and the latter will evaluate to
FALSE. Enjoy."
=> select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
=> select NOT ROW(1, NULL) IS NULL;
?column?
------
t
(1 row)
Regards,
Jeff Davis
--
nt and prior checkpoint are the same, and
redo is before both), a crash, a PANIC, a backup_label.old, and not much
else.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2010-10-15 at 15:58 -0700, Jeff Davis wrote:
> I don't have a fix yet, because I think it requires a little discussion.
> For instance, it seems to be dangerous to assume that we're starting up
> from a backup with access to the archive when it might have been a cra
> simpler than your proposed patch (i.e., check whether REDO location exists).
>
Either is fine with me.
Do users have any expectation that they can restore a backup without
using recovery.conf by merely having the WAL segments in pg_xlog?
Regards,
Jeff Davis
--
Sent via pgsql-bu
On Mon, 2010-10-18 at 17:51 -0400, Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:07 PM, Jeff Davis wrote:
> > On Mon, 2010-10-18 at 17:02 +0900, Fujii Masao wrote:
> >> Yep, to automatically delete backup_label and continue recovery seems to be
> >> dangerous. How abou
y entry and then silently ignores the fact that it
couldn't copy the contents. Another concern is: what if they are using
some kind of filesystem mirroring tool that doesn't take consistent
snapshots (do such tools exist?)? Are there other system-level tools
that people might be using th
On Tue, 2010-10-19 at 09:51 -0700, Jeff Davis wrote:
> On Tue, 2010-10-19 at 12:26 +0300, Heikki Linnakangas wrote:
> > Excluding pg_xlog is just a recommendation at the moment, though, so we
> > would need a big warning in the docs. And some way to enforce that
> > just_ki
kpoint. I haven't tested your
patch yet, but it looks like some of the following code depends on
ReadRecord(NULL,...) fetching the record right after the checkpoint
record; so I think something else is required if you want to use
ReadRecord.
Regards,
Jeff Davis
--
Sent via p
inology issue, however).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
istent to raise syntax errors in all these
> cases.
I don't really see a "bug" here. Is this causing you some kind of
problem?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
he backup, and you'll get a PANIC.
This seems like a pretty serious issue to me (backups could appear
unrecoverable), so please consider this before the next patch-level
release so that the bad fix doesn't go out to the world. Also, you might
want to double-check that there ar
On Thu, 2010-11-11 at 18:20 +0200, Heikki Linnakangas wrote:
> On 11.11.2010 02:20, Jeff Davis wrote:
> > There is a problem with this patch. ReadRecord() not only modifies
> > global variables, it also modifies the location pointed to by "record",
> > which is later
y "reset", I do not mean "overflow". I mean that the
sequence might have been recreated somehow.
Try to provide more detail in your bug report. See:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (p
broot.glob->paramlist, and uses it in
subsequent iterations; but that isn't copied before the context is
reset. It looks like there are other things that need copying as well,
but it wasn't immediately clear to me what the best fix is.
Regards,
Jeff Davis
begin;
create table
mining which files should be removed at recovery time is
challenging?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s worth the
bookkeeping effort though.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> Interesting problem... the bug is in get_op_btree_interpretation() which
> has code like this:
>
> /*
>
>* If we can&#
ll.
PostgreSQL is a SQL DBMS, and in SQL, NULL affects everything. I'm sure
there are places in the documentation that could be improved, but
warnings on every page would be counterproductive.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
http://archives.postgresql.org/pgsql-bugs/2011-06/msg00167.php
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pclasses.
I suppose this is another argument for type interfaces.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> >> Interesting problem... the bug is in get_op_btree_interpretation() which
> >> has code like this:
> >> ...
> >> How
e complex, and I
don't think we have a lot of test coverage in this area (and I didn't
see an easy way to add many tests), so this will need some review.
Regards,
Jeff Davis
rowcmp2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-bugs mailing list (pgsql-bugs
terpretation() so it can return amoplefttype
> and amoprighttype too, but given the small number of callers, an API
> change for it doesn't seem like a problem.
Sounds good to me.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
In branch postgresql/master:
SELECT SUM(SUM(a)) OVER ()
FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
ERROR: XX000: cannot extract attribute from empty tuple slot
Honestly, I'm not sure what the semantics of that are supposed to be. Is
it even allowed by the standard?
Regards,
row. That seems pretty
> useless, so I'm thinking it's not worth back-patching a fix for.
> Comments?
Agreed. I'm not worried about backpatching it.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your s
e of those results is correct?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
a bug", though it appears to work in 8.3.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t operation. When you execute the query, it displays the date
> constant using the now-current datestyle.
Another thought: why does it execute the type input function (which is
dependent on a GUC), but not the cast?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
key item to
sort"), but it's fixed sometime later in the 9.1 series.
If you get rid of the CASE statement, then it still fails in 8.4 and
9.0, but it succeeds in 9.1.0 and beyond.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
1 - 100 of 128 matches
Mail list logo
