the fact that this outer-level PlaceHolderVar shouldn't be there by the
time the complaining code runs.
Kinda surprising that this bug escaped detection this long ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
: there is code in initdb that is supposed to be kept parallel
to this, but it's not currently making any attempt to canonicalize
non-empty locale names. Should we make it do that too?
regards, tom lane
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands
--- which
will be the one first defined in the function, eg the first parameter
if any. I guess I can see how this escaped detection for a long time,
but it's broken for sure. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (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
are necessary here because without them test_field
would be syntactically a table name, not a column name.)
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 7, 2012 at 3:49 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Mar 7, 2012 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It is not a bug. The ALTER ADD ... DEFAULT ... form implies rewriting
every existing tuple of the rowtype
consider reindexing everything.)
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
Claus Stadler cstad...@informatik.uni-leipzig.de writes:
Filtering a Union on constant custom type:
...
Expected: Query optimizer should discard the scan as filter cannot be
satisfied.
I've applied a patch for this. Thanks for the report!
regards, tom lane
--
Sent
information for
someone else to reproduce the problem. What would be good is a SQL
script that reproduces the error from a standing start (empty database).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
doesn't crash for me, in HEAD or 9.0 branch tip. Given the
use of CREATE TABLE AS in a SQL function, I suspect that this is the
same issue fixed in 9.0.7:
Fix dangling pointer after CREATE TABLE AS/SELECT INTO in a
SQL-language function (Tom Lane)
In most cases this only led
if they didn't.
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
=57664ed25e5dea117158a2e663c29e60b3546e1c
I'm starting to think we need to revert that in favor of some other
solution, though I have no idea what yet.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
caches the plan for the query as it was built with
the original search_path. There's been talk of adjusting that behavior
but I'm worried that we might break as many cases as we fix ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
in
verisimilitude or not; but one should never imagine that EXPLAIN is an
exact simulation of normal query execution. It's meant for debugging
planner choices, anyway, and the detoastI/O costs are going to be the
same whichever plan you choose.
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
...
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 will cause 9.2 and later releases to
report an error for this 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
1. If you forget to drop the temp table before ending the script,
then when the session ends and the temp table is forcibly dropped,
the whole extension goes away (following the rule that a forced drop
pretty much a one-liner, and much cleaner
than hacking ON COMMIT DROP. PFA a patch that fixes both of the
temp-table issues.
regards, tom lane
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index a8653cd49562d95748c8fe38517aa1d0785c9aff
TABLE to throw an
error telling you it couldn't cope with updating the rule, and that
you'd need to fix that manually. There is such a test involving views;
not sure why it's not catching this rule.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
It would also have the effect that explicit DROPs of member objects in
extension scripts could be done without an explicit ALTER EXTENSION DROP
first. I think we'd originally decided that requiring the ALTER
not other similar bugs lurking.
Thoughts, better ideas?
regards, tom lane
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index db86262b4f06ec5b78f834eb10fbae45a1e77033..eca064f0cdef7ee6367b76a4da785e29a9cfdbc6 100644
*** a/src/backend
, 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
Phil Sorber p...@omniti.com writes:
On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. If you forget to drop the temp table before ending the script,
then when the session ends and the temp table is forcibly dropped,
the whole extension goes away (following the rule
Sergey Burladyan eshkin...@gmail.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
I think it'd be better to avoid depending on %*s for the data string
and instead use it (with appropriate adjustment of the calculation)
for the space-separator part of the format. Since that's a constant
empty
originally decided that requiring the ALTER was a
good safety feature, but is it really more than nanny-ism? The intent
of a DROP command seems pretty clear.
Thoughts?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
of the format. Since that's a constant
empty string, there shouldn't be any possibility of libc doing something
other than what we intend.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
. At least this should be documented.
There really isn't any way that we can force stderr output from a script
to magically go to syslog. But we can at least clarify the docs, and
I will go do so. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list
this is intentional --- see the comment in exec_move_row.
In any case, I think tightening it up is more likely to break working
applications than do anything helpful.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
this with a suitable setting of listen_addresses?
That is, explicitly specify the V6 and then V4 addresses 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
of a transaction possibly being
committed while the client remains in doubt whether it happened or not.
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? You don't have any loops in the data. In particular that
means there will be no join matches after a certain number of levels.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
a
reconnect and retry. But there's a quite separate question as to
whether the behavior Ryan is claiming for a pre-commit crash is actually
possible. I don't believe it, and I failed to reproduce his test
scenario.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
Christophe Pettus x...@thebuild.com writes:
On Feb 29, 2012, at 1:15 PM, Tom Lane wrote:
But there's a quite separate question as to
whether the behavior Ryan is claiming for a pre-commit crash is actually
possible. I don't believe it, and I failed to reproduce his test
scenario.
Did you
.
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
composite types (Tom Lane)
For example, disallow composite_value.text and
text(composite_value). Unintentional uses of this syntax have
frequently resulted in bug reports; although it was not a bug,
it seems better to go back to rejecting such expressions. The
CAST
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Huh? If the backend dumped core before you sent it the commit,
the data will certainly not be committed. It might be physically
present on disk, but it won't be considered valid.
I suppose
following this recipe, but I don't see how exiting from
the first su there would fix it. All it's likely to do is add extra
steps because you no longer have root permissions to do the second su
with.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
a query plan that involves a Sort
node followed by Limit. We have some optimizations that avoid the need
for an explicit sort, but it would be pretty hard to write a
specification for exactly when unretrieved rows will not be evaluated.
regards, tom lane
--
Sent via pgsql-bugs
Ramanujam innomot...@gmail.com writes:
On Thu, Feb 23, 2012 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is intentional --- we gave up updating index column names awhile
ago.
Is pg_constraint a credible place to retrieve primary key information from?
I'd try the information_schema
?
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
update releases.
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
innomot...@gmail.com writes:
Primary key information in pg_attribute table is not updated when a column
name is renamed.
This is intentional --- we gave up updating index column names awhile
ago.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
is just one of many varieties of fail in that industry. But
yeah, the stated complaint is not by itself a bug, and it would help a
lot if the OP had shown us what he's doing and what happens instead of
jumping to conclusions about why it's not working for him.
regards, tom
idea. On the other hand, if we're printing
informational text, it's not an unreasonable 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
I wrote:
Chris Rees cr...@freebsd.org writes:
On 18 Feb 2012 18:49, Tom Lane t...@sss.pgh.pa.us wrote:
https://redports.org/browser/crees/databases/postgresql91-server/files/patch-config-python-m4
I think we'd need more information before arbitrarily disabling this.
The patch is to disable
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-02-17 at 12:01 -0500, Tom Lane wrote:
lenka.piy...@gmail.com writes:
when i restore a particular table using pg_restore (using option -t) it
doesn't restore my primary key...
This is not a bug. -t selects the table only, not associated
Christoph Anton Mitterer cales...@scientia.net writes:
On Tue, 2012-02-14 at 18:45 -0500, Tom Lane wrote:
cales...@scientia.net writes:
http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
claims that log_filename is only used when logging_collector is enabled
=commitdiffh=bb65cb8cdf864e61bc939d3c4b28bbd43d926700
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
be horribly slow.
Perhaps if you discussed why you think that repeatedly dropping and
re-adding a column is a useful thing to do, we could help you find
another way. The bugs list is not the place for that discussion,
however.
regards, tom lane
--
Sent via pgsql-bugs
, and none of them have shown any sign of not
liking threaded python:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
I think we'd need more information before arbitrarily disabling this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Chris Rees cr...@freebsd.org writes:
On 18 Feb 2012 18:49, Tom Lane t...@sss.pgh.pa.us wrote:
https://redports.org/browser/crees/databases/postgresql91-server/files/patch-config-python-m4
I think we'd need more information before arbitrarily disabling this.
The patch is to disable the error
lenka.piy...@gmail.com writes:
when i restore a particular table using pg_restore (using option -t) it
doesn't restore my primary key...
This is not a bug. -t selects the table only, not associated indexes.
regards, tom lane
--
Sent via pgsql-bugs mailing list
overflow,
Sure they can. Or at least if they can't, it's not because of size_t
being 8 bytes. That code works fine on every other 64-bit platform.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
[ getting back to this after assorted distractions ]
Andres Freund and...@anarazel.de writes:
On Thursday, January 12, 2012 02:24:44 AM Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
Looks pretty bogus to me. You're
albert.cieszkow...@cc.com.pl writes:
OS, base and client encoding UTF-8:
What's your lc_collate/lc_ctype settings?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
look like we're even trying to cache
the results, ick.)
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 logging_collector can't be changed without a postmaster restart
(which is why it's a separate variable from log_destination).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
--- will announce it on pgsql-hackers, so you
can keep an eye on that list if you want advance notice.)
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 be a lot
more efficient than this row_number() = 1 locution anyway.
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
[ in re bugs 6200 and 6425 ]
I've committed patches for all the issues I could find pursuant to these
bug reports. Please see if you can break REL9_0_STABLE branch tip
(or 9.1 if that's what you're working with).
regards, tom lane
--
Sent via pgsql-bugs mailing list
Duncan Rance postg...@dunquino.com writes:
On 3 Feb 2012, at 06:45, Tom Lane wrote:
I probably ought to let the test case run overnight before concluding
anything, but at this point it's run for two-plus hours with no errors
after applying this patch:
Thank Tom! I've had this running
JOINs in the query, the order
can matter.
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
eshkinkot eshkin...@gmail.com writes:
Ah, sorry, looks like it already fixed in
REL9_1_STABLE 5d7d12de56be2c746bfc30214d3300644e8dc0f3
Oh, of course. I couldn't reproduce it because I was testing 9.1
branch tip.
regards, tom lane
--
Sent via pgsql-bugs mailing list
')
to
ts=$$
ie use PID not timestamp as the pseudo-unique key. This could be made
more bulletproof yet, but it didn't seem worth more trouble.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Assert(ItemIdIsNormal(lpp));
(gdb) p lpp
$1 = (ItemIdData *) 0x7fea59705d90
(gdb) p *lpp
$2 = {lp_off = 7936, lp_flags = 1, lp_len = 34}
This suggests very strongly that indeed the buffer was changing under
us.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
about what this says about
the amount of testing Hot Standby has gotten, because AFAICS absolutely
any use of Hot Standby, no matter the particulars, ought to be heavily
exposed to this bug.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
in the build process could be
significant.
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 one of the possible solutions to the problem
being discussed over here:
http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php
but I don't believe we have any consensus yet about whether that
would be a good idea.
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
routine that hasn't been upgraded to acquire sufficient
buffer locks. Pre-hot-standby, there was no reason for them to be
careful about locking.
On the other hand, if that were the cause, you'd expect the symptoms
to be a bit more variable...
regards, tom lane
--
Sent via
available operations. I think you
have to do what the OP suggests here, namely subtract two timestamp
values (forming an interval) and then use extract(epoch from interval).
Ugh.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
complete instructions for duplicating this, we
could probably find the cause fairly quickly.
What I don't get is why this is causing the client to abort, and not the
backend.
As Alvaro said, it's not reaching the abort(). You should use PANIC
instead.
regards, tom lane
-making code gets around to examining the shared memory, the
other process that's hypothetically changing the page will have done its
work and moved on. A crash in process X doesn't freeze execution in
process Y, at least not in any Unixoid system I've ever heard of.
regards, tom
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, after a bit more reflection it occurs to me that it's not so much
that the data is necessarily *bad*, as that it seemingly doesn't match
the tuple descriptor that the backend's
doesn't really seem
like an improvement for typical use-cases. I'm fairly sure this was
debated when the operator was added, and we thought it was an acceptable
limitation; though maybe with IPv6 finally starting to see real usage
it's going to seem less so.
regards, tom
. This is per design
and AFAIK it's per the SQL standard's requirements.
There's a lot of fine print in the Notes sections of the GRANT and
REVOKE reference pages, which you might find helpful.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
such arithmetic into the future mean that we're not
likely ever to try to support it.
So anyway, if you want to propose some documentation corrections,
we're all ears.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
extent.)
Still baffled here.
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
Josh Berkus j...@agliodbs.com writes:
On 1/28/12 5:27 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
SUMMARY: if you attempt to UPDATE or DELETE FROM a parent table in an
inheritance relationship using a wCTE, you get the following error message:
ERROR: could not find plan for CTE
.
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 use-case for passwords longer than
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
Phil Sorber p...@omniti.com writes:
On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I played around with removing the optimization, but there are other
pieces further down the line that are upset but having a ModifyTable
node in the execution tree.
Hm, yeah, obviously
Josh Berkus j...@agliodbs.com writes:
SUMMARY: if you attempt to UPDATE or DELETE FROM a parent table in an
inheritance relationship using a wCTE, you get the following error message:
ERROR: could not find plan for CTE
Fixed, thanks for the report.
regards, tom
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
this.
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
Marko Kreen mark...@gmail.com writes:
On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
I think we should fix and back-patch these two specific bugs. The
openssl.c change sounds like it might be something for HEAD only.
Now I looked more in-depth and seems my comments were off
case fixed here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c1d9579dd
and as noted in that commit message, it didn't appear worth the risk
of fixing it in released branches.
regards, tom lane
--
Sent via pgsql-bugs mailing list (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
good,
and that the only safe fix is to take it out. That code path is
(obviously) none too well tested, so we should not have it setting
up execution tree structures that are not like those used normally.
It's just begging for trouble.
regards, tom lane
--
Sent via pgsql
Phil Sorber p...@omniti.com writes:
On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
How about a test case?
We are having trouble coming up with a test case that can reliably
reproduce this.
The stack traces run through the EvalPlanQual machinery, which is only
going
Phil Sorber p...@omniti.com writes:
I've attached a backtrace.
How about a test case? I have no faith in the proposed patch without
some evidence of what it's supposed to fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
to
compare 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
. The only thing that's in question is whether we should
allow certain errno values to pass without comment.
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 we could add enough
code to verify that there's a match. The latter seems like overkill,
and yet I'm not 100% comfortable with just assuming a collision is OK.
Comments?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
, 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
has a trigger that is doing date_trunc('year',...)
or something like that on the column value.
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
-01-11 | 2012-01-11
2 | 2012-01-11 | 2012-01-11
3 | 2012-01-11 | 2012-01-11
(3 rows)
and it does not remind me of any known/fixed bug in community 8.2.x.
So I'd have to say this is a Greenplum bug.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
as
duplicate_table, which is exactly what the problem is (well, as long
as you know that tables and indexes share the same namespace in PG).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
601 - 700 of 6572 matches
Mail list logo
