i...@avdd.co writes:
In trying 9.2 I find pg_stat_activity.procpid has been renamed to pid.
Yup. Sorry, that change is not going to get undone at this point.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Bruce Momjian br...@momjian.us writes:
On Fri, Jun 22, 2012 at 10:37:10PM -0400, Tom Lane wrote:
j...@pgexperts.com writes:
DROP and CREATE extension appear to work fine, but if you ALTER EXTENSION
postgis SET SCHEMA foo, it leaves a few relations behind.
What it seems to be leaving behind
that, copy the test program above (removing the | indentation),
replace wcstombs_l by mbstowcs_l, and then try to compile it ---
but be sure to use the compile command shown in your config.log, not
mine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
code, ie, the fault is not with the estimate but the
reality. It's hard to tell about that though. Do you want to try to
make up a smaller self-contained test case?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
.
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 value
of allowing them to be more than 100 characters ...
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
checks, though.
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 a DNS name resolution delay. But it'd be less
likely to result in strange crashes.
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
Amit Kapila amit.kap...@huawei.com writes:
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
None of the system columns are set at the time check constraints are
checked.
Is there any problem if set tableOID before calling ExecConstarints
and don't get inherited to children. I think use of such
constraints is probably better design than mucking around with tableoid,
even if we were to make that work.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
.
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
Chris Travers ch...@metatrontech.com writes:
My guess is that tableoid is not known when the check constraint is
checked.
None of the system columns are set at the time check constraints are
checked.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
the functional
limitations associated with that, so we're very unlikely to do anything
towards changing the existing behavior of SRFs-in-target-lists, no
matter how wacko they might appear.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Chris Travers ch...@metatrontech.com writes:
On Wed, Aug 22, 2012 at 8:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Chris Travers ch...@metatrontech.com writes:
mtech_test=# explain analyze select (account_heading__list()).* group by accno
Hm, that really ought to throw an error, since you have
that column is equal.
As long as you haven't done that, you are wrong, and you are wasting
both your time and ours arguing about it. You've wasted quite enough
of my time already; don't expect to see any further responses on this
subject.
regards, tom lane
--
Sent via pgsql
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 21, 2012 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Meanwhile, back at the ranch: I'm fine with applying that patch now that
it's had some field testing.
Attached is a version that applies OK to 9.1, after resolving some
conflicts
field testing.
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 get to disk
just before the last checkpoint.) However, unless you've been running a
PITR archiving setup, you probably haven't got that option.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
, or to
select any subset of the equivalent rows for a LIMIT query.
It's not completely nondeterministic, of course, but I suspect
if you examine EXPLAIN results you'll find that different query
plans got chosen for the queries with and without LIMIT.
regards, tom lane
--
Sent
)?
Or actually, maybe we could just unconditionally define
HAVE_XMLSTRUCTUREDERRORCONTEXT in pg_config.h.win32. Is anybody
likely to still be building PG with ancient libxml on Windows?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Thom Brown t...@linux.com writes:
On 12 August 2012 08:17, Thom Brown t...@linux.com wrote:
On 12 August 2012 01:06, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM we ought to disallow that ... either the schema is inside the
extension, or vice versa, it's not sensible to say both.
Precisely
it?
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
Adam Mackler adammack...@gmail.com writes:
On Wed, Aug 15, 2012 at 12:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right offhand I'm inclined to think that the reference to iter
inside the first sub-WITH ought to be disallowed. I don't recall
the exact rules about where a recursive reference can
would take that to mean that a unitless
number directly to the left of an hours field is days. Anyway, the
code in DecodeInterval is treating these cases the same.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
, check the encoding setting in
Preferences ... Settings, and also look at Preferences ... Encodings.
You'll probably have trouble unless Terminal is using the same encoding
that psql thinks the client_encoding is.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
in there? Not sure.
Technically it wouldn't be very hard, but I seem to recall this was
discussed before and we were worried about whether people would be
confused about what ms means. Don't know that us would be
universally recognized, either.
regards, tom lane
--
Sent
those data structures are supposed to survive for the life of the
pg_dump run, so this isn't a leak.
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 disallow that ... either the schema is inside the
extension, or vice versa, it's not sensible to say 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
wasn't expecting.
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 shorthand for creating an
integer (or bigint) column, creating a sequence, associating them
as though by ALTER SEQUENCE OWNED BY, and setting the column's default
to nextval('sequence-name').
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
the behavior change if you
build without openssl?
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
=?UTF-8?Q?Gr=C3=A9goire_Hubert?= gregoire.hub...@knplabs.com writes:
2012/8/2 Tom Lane t...@sss.pgh.pa.us:
Just to try to narrow things down a bit: does the behavior change if you
build without openssl?
It works : psql (9.3devel) \o/
Hmm. The first reaction is to guess that there's
.
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
something. In any case,
I'm thinking this is a build error and not anything to do with the
Postgres source code.
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
).
The only real reason it complains about simple constants is that
otherwise people might think ORDER BY 1 means something different
than what it does mean according to SQL92. Otherwise, if you want
to sort by a constant, who are we to stop you?
regards, tom lane
--
Sent
.
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
was a lot more than the 8K that the
planner assumes when dealing with array_agg. But neither of those
errors seems to be happening in this example case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
, but the point is that the
expression 'now'::timestamp will get folded to a timestamp constant during
planning, and then not replanned later. As Pavel says, it's a lot safer
to use one of the variants of the now() function.
regards, tom lane
--
Sent via pgsql-bugs mailing
The previous complainant didn't help us do anything to resolve the
problem, but maybe you can help more.
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
by the kernel.
Is there any reason to think this is an actual leak, and not just you
were trying to compute an impractically large value?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
, but considering all the other
xlog entries involved in creation of a sequence object, this is a pretty
silly optimization. (Besides, it merely postpones the first
nextval-driven xlog entry from the first to the second nextval call.)
regards, tom lane
--
Sent via pgsql-bugs mailing list
.
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
() function tells us to.
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
) there is more than one version of MULE (emacs versus xemacs,
not to mention any possible cross-version discrepancies).
(3) from a log volume standpoint, this could be pretty disastrous.
I'm not for a write-only solution, which is pretty much what this
would be.
regards, tom lane
on extension of relation
60777 of database 16387 after 1000.183 ms
Apparently you've got log_lock_waits turned on.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
git source and test
that, it would be great!
The only thing I see that looks likely to represent a platform-specific
issue is the entrysize calculation. Mike, just out of curiosity, could
you see if the attached patch makes things better for you?
regards, tom lane
diff
Noah Misch n...@leadboat.com writes:
As a side question for the list, should we fix this differently in 9.2 to
avoid forcing an initdb for the next beta?
I'm confused, why would an initdb be involved?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
a fix for this in 9.2 and up. The issue exists since
CREATE TABLE LIKE grew the ability to copy comments, in 9.0, but
it seems too risky to fix in already-released branches.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
is for you to debug it yourself or let
one of the PG developers have access to your system to poke at it.
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
included a segfault. In any case,
I'd suggest making sure the new cluster is initdb'd under the same
account that currently owns the old cluster.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
that they might
have to have any downtime 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-bugs
at the instant of index creation.
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 only safe thing.
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
go away for you if we changed the order in
which these libraries are probed for? That's a hack, surely, but it
seems like one much less likely to break other working cases than any
of the alternatives you suggest.
regards, tom lane
--
Sent via pgsql-bugs mailing list
versions to install their stuff into .../lib64/ not .../lib/.
Not sure how practical such a change is at this late date.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
/future? Could we see the output
of pg_controldata for both old and new clusters?
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
hard to find where.
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
=postgresql.gita=commitdiffh=268ca4f57ea2dc3bf0dfb0f5c17fbda269b5d462
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 test this that pg_upgrade is
currently completely broken for the case of taking PGDATAOLD or
PGDATANEW from the environment rather than switches. This is because
the existing coding in option.c fails to set up the pgconfig fields
in such cases.
regards, tom lane
the transformation of regexes to index conditions in a
different way, it might be practical to suppress the redundant test,
but given the way the code is structured we can't easily.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
()
is flat-out broken when applied to a non-absolute head path.
Not sure about what a useful solution would be.
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
and back-patched to 9.2.
I do not believe that this patch fixes the problem, and I also believe
that it creates new problems. Please revert.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
-binary-upgrade cases, and it does nothing at all to
address the points I made about reproducing the previous state in cases
where the admin removed the language or changed its permissions.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Bruce Momjian br...@momjian.us writes:
On Fri, Jun 29, 2012 at 11:35:15PM -0400, Tom Lane wrote:
I think you're misjudging the core of the issue. The same thing
would happen if somebody dropped and recreated the public schema.
Or anything else that we create at initdb time but allow
(2 rows)
which is the correct way of indicating they belong to the database's
default tablespace. Are you perhaps misinterpreting the zero as meaning
they'll be in pg_default?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
else that we create at initdb time but allow to be
dropped.
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
or ConvertRowtypeExpr)?
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
perpetrated.
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
or all of these three error
cases to PANIC, as they certainly suggest shared-memory corruption.
And if it did panic, we could hope to get a core dump for debugging
purposes.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make 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
round of refactoring in this
area, but for sure it's broken now.
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
listen to it if it does say
that these values are not distinct. They certainly *look* distinct.
(Oh, and dare I mention arrays of nulls?)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
It's not clear to me whether the SQL standard rules on what should
happen in this case, or whether we should listen to it if it does
say that these values are not distinct. They certainly *look*
distinct
in the node's state. (I thought first
about trying to pfree the prior contents of prm-value itself, but I'm
less sure that that is safe --- if memory serves, the same ParamExecData
slot can sometimes be used for multiple purposes.)
Will give it a try ...
regards, tom lane
--
Sent
/functions-comparison.html
(I'm not that thrilled with this behavior either, but it is per SQL
standard AFAICT.)
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 way in older branches, we're going to have to
back-port parts of that commit. I don't actually see any alternative
way to fix it, though. How concerned are we about making this work
in released branches?
Comments?
regards, tom lane
diff --git a/src/bin/pg_dump
such FK constraints being restored
serially at the end, because the parallel loop never manages to clear
all of their dependencies. Surprising nobody's complained about that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
in the
dump file.
Hmm ... check_functional_grouping does add the PK's OID to the query's
constraintDeps list. Apparently we're losing that dependency knowledge
somewhere between the parser and pg_dump?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
very nice ideas about exactly how
to refactor, though. Thoughts?
regards, tom lane
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index aa9c8eed5dafabd49429874d973e22abe93d5294..2db67d6fd3d5616944ff0b086aa606af11e9eed4 100644
are sane to begin with.
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
need full instructions to reproduce the
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
it should be called in the comparison function for
every node type that has a token location field (some do, some don't).
So far as I can see, it is called where it should be. Did you observe a
place where it is not, and if so where?
regards, tom lane
--
Sent via pgsql
the header
comments for ChangeVarNodes and OffsetVarNodes.
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
terribly consistent perhaps, but it's what's required by the SQL
standard.
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 drop the dependency case in
changeDependencyFor().
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
worth it. There are any number of ways
that the restore step can fail, and it's impossible for pg_upgrade
to pre-check for all of them.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
. There is no reason that we should discriminate
against that case.
It also does not seem to me like a good plan to insist that identd be
running at the same instant initdb runs; it's not hard to think of
installation scenarios where that won't be true.
regards, tom lane
for the popen call in adjust_data_dir.
if that actually is a third bug, as seems likely, somebody with access
to a windows environment will need to deal with it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Edmund Horner ejr...@gmail.com writes:
On 12 June 2012 14:23, Tom Lane t...@sss.pgh.pa.us wrote:
Hm, that patch seems to be several bricks shy of a load. I will fix
two obvious bugs in it:
(1) not dump core on boxes where printf(%s, NULL) dumps core;
I saw that, but I couldn't decide
Craig Ringer ring...@ringerc.id.au writes:
On 06/10/2012 06:14 AM, Tom Lane wrote:
phb.e...@free.fr writes:
When a table having a seial column has been created by a CREATE EXTENSION,
and when this table is later dropped from the extension, the associated
sequence must be also explicitely
://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=fbcf4b92aa64d4577bcf25925b055316b978744a
As noted there, the change wasn't back-patched for fear that the
stronger lock on the parent table might be an undesirable behavioral
change for some applications.
regards, tom lane
--
Sent
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 4, 2012 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And so is that. IMO the error reporting in this module could stand to
be reviewed altogether for compliance with our message guidelines.
(For starters, why is it using
pg_catalog.pg_extension_config_dump('tbl1_col1_seq','');
This test proves nothing of the kind. Please read the error message:
ERROR: pg_extension_config_dump() can only be called from an SQL script
executed by CREATE EXTENSION
You have to do it in the extension's script.
regards, tom lane
to set clocks by local mean solar time, which is 1:39:52 east
of Greenwich.
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
different, even though the time zone is the same.
No, the query result is the same, it's just more fully specified.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
done enough updates since the last checkpoint, it would do
one. So this isn't a bug, but an intentional reduction in checkpoint
frequency. (Note that sending SIGINT is not, and never has been,
equivalent to forcing a checkpoint.)
regards, tom lane
--
Sent via pgsql-bugs
://archives.postgresql.org/pgsql-hackers/2012-06/msg00160.php
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
we promise that geometric operations involving
infinite endpoints will behave sanely. There are probably a boatload
of corner cases besides this one that'd need to be fixed before we
could consider that a supported case.
regards, tom lane
--
Sent via pgsql-bugs mailing
401 - 500 of 6572 matches
Mail list logo
