, even though the
description says scaling/rotation.
Would someone who uses these features please post changes and I will see
that get into the docs? Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's
...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce
Robert Haas wrote:
On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian br...@momjian.us wrote:
Was this fixed?
Not yet. I can probably fix it, if nobody else wants to do it.
Well, it has languished for five months, so the nobody else wants part
is probably accurate. ;-)
--
Bruce Momjian
enter, no is the default.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
doc patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
new file mode 100644
index c65f852
is only provided there
is easily missed when someone goes to read up on a particular
switch.
I have applied the attached doc patch to reference the example section
from the specific pg_dump options sections.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
Robert Haas wrote:
On Sat, Feb 26, 2011 at 2:14 AM, Bruce Momjian br...@momjian.us wrote:
Has this been addressed?
Not me. Sounds like no one cares enough to figure out how to do this.
Perhaps this should be a TODO.
Agreed. TODO added:
Fix cross-compiling on Windows
://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
and
counts are for non-FULL vacuums; applied patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml
=1
width=32)
Index Cond: (a '1.0.0.0'::inet)
(2 rows)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
, which will be fine from the developers point of
view.
Based on this report and later discussion, I have applied the attached
documentation patch to warn users about the Postgres behavior of
information_schema.referential_constraints.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
effort though.
I thought we had a TODO item about removing orphaned files, but I don't
see it now, perhaps because I thought we had fixed that.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
Christopher Head wrote:
On Wed, 14 Jul 2010 18:35:55 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Do the docs need any more updating?
No doubt, but it's a bit premature to consider that while we're still
arguing whether the code needs to change
it.
Are we going to make the allow_system_table_mods to SUSET change? Is it
a TODO?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs
you have in mind?
\i is a psql client command, not something the backend runs.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list
result, convert_from helps out:
select convert_from(decode(encode('abc', 'base64'), 'base64'), 'UTF8');
Still, shouldn't this be consistent with 8.x and 9.x?
Uh, they look the same to me. cut/paste error?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
Robert Haas wrote:
On Wed, Dec 22, 2010 at 8:45 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Grant Hutchins and Peter Jaros gr...@pivotallabs.com writes:
The unaccent(text) function supplied by contrib/unaccent is marked
VOLATILE.
This prevents it from being used
/pgsql-bugs/2010-12/msg00032.php
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
configuration files
which are easily changeable.
Arguably it'd be reasonable to change the function's marking from
volatile to stable, but that's not going to be enough to allow use in
indexes.
So, should we change unaccent() from VOLATILE to STABLE?
--
Bruce Momjian br...@momjian.us
on
SELECT documentation page
Details:
Inefficiency of large offsets should be mentioned on SELECT documentation
page - now it's only on LIMIT and OFFSET page.
I have no idea what you are suggesting. There is no LIMIT and OFFSET
page in the manuals.
--
Bruce Momjian br...@momjian.us
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql
.''
Unfortunately, I could not understand in full detail the above.
Thanks,
arturas
[1] http://www.postgresql.org/docs/9.0/static/pgupgrade.html
I have added a mention about 32/64-bit isssues to the pg_upgrade manual
page, attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On 10/30/2010 7:33 PM, Dave Page wrote:
upgrade from a 32bit 8.3 server to a 64 bit 9.0 server, which isn't
going to work without a dump/restore. With pg_upgrade, the two builds
need to be from the same platform, same word size
?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
at that in the next few weeks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
the
issue you're having, though.
pg_upgrade works for upgrades from 8.3 to 9.0.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql
:
SELECT 1;
COMMIT;
SELECT 1;
I seem to recall testing out similar situations during my review of this
patch, but I think the code has changed since that time.
So the problem report is? I tested it and the problem is that the final
SELECT 1 hung. Is that the problem?
--
Bruce
Bruce Momjian wrote:
Jeff Davis wrote:
In honor of the very first bug report I sent to postgresql more than 10
years ago regarding UNLISTEN[1], I have decided to submit another
UNLISTEN bug (against HEAD):
Session1:
LISTEN foo;
BEGIN;
UNLISTEN foo;
Session2
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql
reusing the same validation code for this and other
min_messages settings. Is it worth creating a custom one just for
client_min_messages? Probably not.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
Bruce Momjian br...@momjian.us
Alexsander Rosa wrote:
What about the risk of using ALTER SEQUENCE ... START N in a mixed
environment? In the 8.4.x servers it will work as designed but in the
8.3.x
(and below) servers, instead of issuing an error it will CORRUPT the
sequence value
, was an (unintended) alias to
RESTART -- with the wording you suggested or something like that. The advise
to check server_version when using this command could be mentioned, also.
I don't think we have had enough people confused by this to add that
level of detail.
--
Bruce Momjian br
run
fails on an error loading /opt/postgres/8.4.1/lib/plpgsql.o.
What is the error? What old version of PG are you migrating from?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything
data are not strings, they are delimited data, so
there is no standard to match here.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
David Platt wrote:
The following definition is my database:
CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler
LANGUAGE c
AS '/opt/postgres/8.4.1/lib/plpgsql', 'plpgsql_call_handler';
The file /opt/postgres/9
using.
regards, tom lane
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
reported failure we have heard about this. Where did you get
the Postgres download from?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing
depst...@alliedtesting.com wrote:
Bruce Momjian wrote:
depst...@alliedtesting.com wrote:
I am trying to obtain a binary dump of a small test database where
this issue could be reproduced, but so far, no luck. At present,
the
least such database is 1.5 GB compressed and contains
Robert Haas wrote:
On Sat, Jul 24, 2010 at 11:37 PM, Bruce Momjian br...@momjian.us wrote:
I am inclined to prevent pg_upgrade from migrating any database that
uses any of these reg* data types, and document this restriction. ?I
probably could allow regtype because that pg_type is preserved
issues, or just general
movability issues?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Bruce Momjian wrote:
depst...@alliedtesting.com wrote:
I am trying to obtain a binary dump of a small test database where this
issue could be reproduced, but so far, no luck. At present, the least
such database is 1.5 GB compressed and contains a lot of proprietary
info. I would welcome
Bruce Momjian wrote:
I have applied the attached patch to CVS HEAD and 9.0 that prevent
migration when any reg* data type is used in a user table (except
regtype because pg_type.oid is preserved).
I documented this restriction. Thanks again for the report.
Attached is a secondary patch
is preserved.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
for authentication. I don't feel any need
to expose Kerberos' peculiarity 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
--
Bruce Momjian br
attaching the patch fix that will appear in 9.0 beta4.
Fortunately this problem only happens in copy mode, and only when the
copy fails, as you saw.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going
drops. From looking in the
documentation, there is no reference to the maximum size of the string that
his function can process.
Can you show us any relevant entries in the server logs? FYI, 8.1.18 is
both old for minor and major release.
--
Bruce Momjian br...@momjian.ushttp
Hiroshi Saito wrote:
Hi.
Ooops, I can't follow your quick thread
sorry, It will be a weekend if allowed.
I have replied and I think I have it fixed.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
, and cvs.pgfoundry.org is down right
now. Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
a carriage return
is added (\n) to the last column and then a quote is added.
a,b,c,d
e,f,g,h
Can some point me a fix for this ?
I think you need to report this to pgadmin:
http://www.pgadmin.org/
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
targeting just new keywords, but I am worried that
would cause more problems than it fixes.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list
+
Startup Cost: 0.00 +
Total Cost: 9.53 +
Plan Rows: 253 +
Plan Width: 190
(1 row)
Is unquoted identifiers the only value for YAML?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
So, is there still value to a YAML format vs. JSON? They look similar
to me in this simple case:
Well, removing the various braces and brackets reduces the line count
significantly. Not convinced it's really worth much though.
Ah
. (Yeah, I am serious.)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
later application failure?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
to run around fixing
them. (FYI, pg_upgrade would use the new pg_dump and would not fail.)
I think it is quite a stretch to consider this a feature.
How about a desireable behavior considering the alternatives?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
many
PostgreSQL developers realize; and I think it makes a reasonable
case for at least an *option* to quote all identifiers emitted by
pg_dump.
Even if we quote them in the dump, I assume applications would need to
quote them too, which I doubt many do.
--
Bruce Momjian br...@momjian.us
David Fetter wrote:
On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
Kevin Grittner wrote:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
The application already quotes all column names :-) It's using a
generic framework which does not (and must not) rely
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have documented this citext limitation with the attached, applied
patch.
Are you planning to insert similar verbiage into every other contrib
module's docs?
Uh, do they all have this odd behavior? Most people assume they would
get
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, May 31, 2010 at 10:11 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian br...@momjian.us wrote:
I have updated the patch, attached, to clarify that this returns text
arrays
Markus Wichitill wrote:
On 03.06.2010 05:05, Bruce Momjian wrote:
The schema containing the typecitext/ operators must be
in the current varnamesearch_path/ (typically literalpublic/);
It's been a while, but the way I read my own example is that the schema
containing the citext operators
as the table
using it.
Interestingly we recently got another report of this same problem.
Tom did some analysis of it here:
http://archives.postgresql.org/pgsql-bugs/2010-03/msg00017.php
I have documented this citext limitation with the attached, applied
patch.
--
Bruce Momjian br
don't use 'g' as a third argument, it can't return more than one
row.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Robert Haas wrote:
On Mon, May 31, 2010 at 10:11 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian br...@momjian.us wrote:
I have updated the patch, attached, to clarify that this returns text
arrays, and that you can force
Daniele Varrazzo wrote:
On Sun, May 30, 2010 at 4:45 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian br...@momjian.us wrote:
I have updated the patch, attached, to clarify that this returns text
arrays, and that you can force it to always return
:
Consider improving overflow detection
*
http://archives.postgresql.org/message-id/4bc66a57.2030...@cs.utah.edu
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Consider improving overflow detection
*
http://archives.postgresql.org/message-id/4bc66a57.2030...@cs.utah.edu
I did look at those at the time, and saw absolutely no reason to prefer
them over what we do now.
OK
.
RETURNS TABLE is just a shorthand for some OUT parameters. ?I don't
believe it's either easy or a good idea to make it work differently
from every other function-argument-or-result case.
I don't know now. It minimally have to be documented
Can you suggest some documentation?
--
Bruce
Applied.
---
Bruce Momjian wrote:
Tom Lane wrote:
Matt Nourse matt...@nplus1.com.au writes:
CREATE DOMAIN test_id_domain INT NOT NULL;
CREATE TABLE test_state(id test_id_domain PRIMARY KEY, display_value
is clearer about the
behavior of regexp_matches().
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/func.sgml
===
RCS file: /cvsroot/pgsql/doc
out that optimization?
Yea, looks like it is this code in like_match.c:
/* %_ is the same as _% - avoid matching _ repeatedly */
do
{
NextChar(t, tlen);
NextByte(p, plen);
} while (tlen 0 plen 0 *p == '_');
--
Bruce Momjian br
patch this and the fix will appear in the next minor release of
Postgres 8.3.X and 8.4.X.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-bugs mailing
statements.
Tom
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
().
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/func.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision
'. However, I assume pg_hba.conf could allow
you do make this work somehow, but with little security.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
.
The post-install script doesn't seem to fix it, either.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
need to know if the brackets are normal when all the privileges are
remove. Or how to reset the privileges (ACL) to default (null).
They are the same.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via
you want
to revoke owner permissions on the table.
Where are you seeing this ACL?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
381
.
.(Omission)
.
Q1:Does anything have same reports ?
Q2:Does anything have repair patches ?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian
\cu as a shortcut for this
query!!
Add this to your ~/.psqlrc:
\set mon 'SELECT * FROM pg_stat_activity';
and then you can use this in psql:
test= :mon
datid | datname | procpid | usesysid | usename | application_name |
...
--
Bruce Momjian br
for
it when it is announced.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
. But it can happen.
I did not see it documented anywhere. Should we at least add a comment at the
top of pg_dump documenting this behavior? Attached is a proposed patch using
your own words.
Applied, thanks. I also added the URL of the discussion.
--
Bruce Momjian br...@momjian.ushttp
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
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?
+1. It likely wouldn't be real hard to fix, but given
is makes input and output relative to the then-current time
zones rather than fixed wall-clock times.
We should probably add this to the FAQ -- the OP was expecting
the behavior specified by the standard, in which TIMESTAMP WITH
TIME ZONE includes a time zone.
-Kevin
--
Bruce Momjian br
list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Anybody know what Oracle's to_timestamp does?
The old thread reported Oracle returned an error;
http://archives.postgresql.org/pgsql-bugs/2009-06/msg00100.php
Well, nothing's likely to get done about
/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs
/pgsql-bugs
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs
Was this ever addressed?
---
Jeff Davis wrote:
On Thu, 2009-03-26 at 21:45 -0400, Bruce Momjian wrote:
http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php
It may or may not be a real bug, but I 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
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Was this ever addressed?
No, it doesn't look like the code's been changed. I was looking for
some comments about which to do:
I can see two reasonable ways to address this:
* Change the ltree test to reject only ARR_NDIM 1
and it is giving some random value, whereas I am
expecting some error message like date is not valid.
Is it an expected behaviour?
--
Thanks Regards,
Dhaval Jaiswal
EnterpriseDB
Contact: 732-331-1300 Ext- 2022
+91-20-30589 516 / 494
web: www.enterprisedb.com
--
Bruce Momjian
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
FYI, this behavior now returns:
test= select to_timestamp('20096010','MMDD');
to_timestamp
2013-12-18 00:00:00-05
(1 row)
which doesn't have the :30 but is still odd
--- for instance a Java version of pg_ctl wouldn't 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-bugs
--
Bruce Momjian br...@momjian.us
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
Was this ever addressed?
It should probably be on the TODO list. I was going to try to do
this along with other items which came out of generating an LSB
conforming init script, but have been pulled in different directions
. What's needed in
pg_ctl's case is just a pointer for the uninformed, at least for me
that'd have sufficed.
Based on your suggestion, I have documented the use of PGHOST by pg_ctl
with the attached patch. I specifically mentioned the socket location.
--
Bruce Momjian br...@momjian.us
?
Fixed with the attached patch. I think HH and HH24 should be the same
for intervals. It is hard to explain why zero hours should show as
'12' for intervals.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East
Bruce Momjian wrote:
Dave Page wrote:
This was posted as a documentation comment:
to_char(interval '0d 0h 12m 44s', 'DD HH MI SS');
with HH and HH12 will return 12 instead of 0.
Testing on 8.4.1, it does seem to be the case that you get 00 12 12
44. Seems bogus to me, but am I
201 - 300 of 1336 matches
Mail list logo
