A. Kretschmer *EXTERN*
Well, I can easily make it do what you expect, and I don't see many
error returns in that area of the code, so I just wrote a patch that
does what you would expect rather than throw an error.
Well, that's great and better than an error, thx.
test= select
2010/3/3 Andrew Dunstan and...@dunslane.net:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
dll?
Curious indeed, because it passed yesterday, *after* I had made all
those changes in contrib/xml2
Hi,
KaiGai Kohei írta:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Koheikai...@ak.jp.nec.com:
Is it an expected behavior?
postgres= CREATE SEQUENCE s;
CREATE SEQUENCE
postgres= ALTER TABLE s RENAME sequence_name TO abcd;
ALTER TABLE
postgres= CREATE
Theo Schlossnagle wrote:
I didn't look deeply at the postgres internals to see if there was a way to do double
- numeric and integer-types - numeric without intermediary string format. If
that sort of thing is easy to leverage, I'd be happy to share the code.
I think your code could be
2010/3/3 Yeb Havinga yebhavi...@gmail.com:
Theo Schlossnagle wrote:
I didn't look deeply at the postgres internals to see if there was a way
to do double - numeric and integer-types - numeric without intermediary
string format. If that sort of thing is easy to leverage, I'd be happy to
Pavel Stehule wrote:
2010/3/3 Yeb Havinga yebhavi...@gmail.com:
Theo Schlossnagle wrote:
I didn't look deeply at the postgres internals to see if there was a way
to do double - numeric and integer-types - numeric without intermediary
string format. If that sort of thing is easy to
2010/3/3 Yeb Havinga yebhavi...@gmail.com:
Pavel Stehule wrote:
2010/3/3 Yeb Havinga yebhavi...@gmail.com:
Theo Schlossnagle wrote:
I didn't look deeply at the postgres internals to see if there was a way
to do double - numeric and integer-types - numeric without
intermediary
string
Magnus Hagander wrote:
2010/3/3 Andrew Dunstan and...@dunslane.net:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Baiji is now failing, however. Perhaps it is not finding the XSLT lib or dll?
Curious indeed, because it passed yesterday, *after* I had
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao masao.fu...@gmail.com wrote:
If standby_mode is enabled, and neither primary_conninfo nor restore_command
are set, the standby would get stuck. How about forbidding (i.e., causing a
FATAL message) this wrong setting?
Here is the patch which forbids
On Tue, Feb 23, 2010 at 1:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
recovery.conf.sample has the following section for Hot Standby.
Is this still required?
#---
# HOT STANDBY PARAMETERS
On Fri, Feb 26, 2010 at 2:34 AM, Josh Berkus j...@agliodbs.com wrote:
If you're adventurous enough, it's actually possible to set an
archive_command that checks the status of the standby and returns
failure as long as the standby still needs the given WAL segment. That
way the primary doesn't
2010/3/3 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Koheikai...@ak.jp.nec.com:
Is it an expected behavior?
postgres= CREATE SEQUENCE s;
CREATE SEQUENCE
postgres= ALTER TABLE s RENAME sequence_name TO abcd;
ALTER TABLE
postgres=
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
It's not clear what it should return, a TLI corresponding the filename
of the WAL segment the record was replayed from, so that you can use
pg_xlogfile_name() to find out the filename of the WAL segment being
replayed,
Albe Laurenz wrote:
But stop, now i see:
test=*# select to_date('2010-02-29', '-MM-DD');
to_date
2010-03-01
(1 row)
So it is maybe a congruously behavior ;-)
Ugh. I thought that to_date was an Oracle compatibility function.
SQL select
I can't release all of it, but the functions to convert uint64_t, int64_t and
double to numeric Datum are the meat and I can expose those...
https://labs.omniti.com/pgsoltools/trunk/contrib/scratch/pg_type_to_numeric.c
As I mentioned, the dscale on the double_to_numeric is imperfect resulting
Andrew Dunstan and...@dunslane.net writes:
It's not working on mastodon, and presumably will fail again on baiji.
I notice that mastodon does not appear to have the presumed location of
the iconv and xslt DLLs in the PATH it sets. That would be a plausible
explanation of the problem ;-)
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
It's not working on mastodon, and presumably will fail again on baiji.
I notice that mastodon does not appear to have the presumed location of
the iconv and xslt DLLs in the PATH it sets. That would be a plausible
On Tue, Mar 02, 2010 at 07:33:47PM -0500, Andrew Dunstan wrote:
There appears to be some significant misunderstanding of what can be
done effectively using the various *_init settings for plperl.
In particular, some people have got an expectation that modules
loaded in plperl.on_init will
Tim Bunce wrote:
FYI the maintainers of Safe are aware of (at least) two exploits which
are being considered at the moment.
You might want to soften the wording in
http://developer.postgresql.org/pgdocs/postgres/plperl-trusted.html
There is no way to ... is a stronger statement than can be
On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
Well, we could put in similar weasel words I guess. But after all,
Safe's very purpose is to provide a restricted execution environment, no?
We already do, in our license.
Joshua D. Drake
cheers
andrew
--
On 3 March 2010 14:34, Bruce Momjian br...@momjian.us wrote:
Scott Bailey wrote:
Tom Lane wrote:
Asher Hoskins as...@piceur.co.uk writes:
I can't seem to get to_timestamp() or to_date() to work with quarters,
The source code says
* We ignore Q when converting to date
Brendan Jurd wrote:
Well, I can easily make it do what you expect, and I don't see many
error returns in that area of the code, so I just wrote a patch that
does what you would expect rather than throw an error.
? ? ? ?test= select to_date('2010-1', '-Q');
? ? ? ? ?to_date
? ? ?
Brendan Jurd dire...@gmail.com writes:
For example, you're trying to import a date that is written as Wed
3rd March, Q1 2010. You might give to_date a format string like 'Dy
FMDDTH Month, QQ ' and expect to get the correct answer. If we
start throwing an error on the Q field, then users
Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
For example, you're trying to import a date that is written as Wed
3rd March, Q1 2010. You might give to_date a format string like 'Dy
FMDDTH Month, QQ ' and expect to get the correct answer. If we
start throwing an error on the
On 4 March 2010 04:08, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
For example, you're trying to import a date that is written as Wed
3rd March, Q1 2010. You might give to_date a format string like 'Dy
FMDDTH Month, QQ ' and expect to get the correct answer.
Bruce Momjian br...@momjian.us writes:
Here is an updated patch that honors 'Q' only if the month has not been
previously supplied:
That's just weird. It's not even self-consistent much less
unsurprising --- having the behavior be dependent on field order is
really horrid.
I think what people
if (p1 buf)
++ * --p1;
else {
++ * --p1; ???
does it even compile ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 Mar 2010, at 17:41, Grzegorz Jaskiewicz wrote:
if (p1 buf)
++ * --p1;
else {
++ * --p1; ???
does it even compile ?
Oh, I can see, that it is *(--p1)++ ,mea culpa.
Which doesn't change the fact, that the code is rather messy imo.
--
Sent via
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Here is an updated patch that honors 'Q' only if the month has not been
previously supplied:
That's just weird. It's not even self-consistent much less
unsurprising --- having the behavior be dependent on field order is
really
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Exactly. With Fedora respecting the standard in this regard, I'm
convinced we should, too. In reviewing things based on Peter's
question, I did start to have doubts about *not* special-casing
status -- it has its own set
Where are we on this?
---
Andrew Dunstan wrote:
It seems like Custom GUCs are still in need of some work, as shown in my
recent email. In particular, they are not transaction safe - if a
transaction attempts to do
I whittled my 1.5k open emails down to a handful and have updated the
9.0 open items list with the items I feel should be addressed before
beta:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs
I added only five items. Of course, I doubled the list size too. :-(
I will
Nowhere, really. I tried to fix it, but could not come up with anything
remotely clean.
cheers
andrew
Bruce Momjian wrote:
Where are we on this?
---
Andrew Dunstan wrote:
It seems like Custom GUCs are still in
Andrew Dunstan wrote:
Nowhere, really. I tried to fix it, but could not come up with anything
remotely clean.
So it is something for the TODO list or a 9.0 open item?
---
cheers
andrew
Bruce Momjian wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Nowhere, really. I tried to fix it, but could not come up with anything
remotely clean.
So it is something for the TODO list or a 9.0 open item?
It's not new, AFAIK. So arguably fixing it could just be a TODO. I don't
have time right
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Nowhere, really. I tried to fix it, but could not come up with anything
remotely clean.
So it is something for the TODO list or a 9.0 open item?
It's not new, AFAIK. So arguably fixing it could
Joshua D. Drake wrote:
On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
Well, we could put in similar weasel words I guess. But after all,
Safe's very purpose is to provide a restricted execution environment, no?
We already do, in our license.
True. I
(2010/03/03 22:42), Robert Haas wrote:
2010/3/3 KaiGai Koheikai...@ak.jp.nec.com:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Koheikai...@ak.jp.nec.com:
Is it an expected behavior?
postgres=CREATE SEQUENCE s;
CREATE SEQUENCE
postgres=ALTER TABLE s RENAME
On Wed, Mar 3, 2010 at 6:28 PM, Bruce Momjian br...@momjian.us wrote:
I whittled my 1.5k open emails down to [five items]
That's a pretty good compression ratio.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2010/3/3 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/03/03 22:42), Robert Haas wrote:
2010/3/3 KaiGai Koheikai...@ak.jp.nec.com:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Koheikai...@ak.jp.nec.com:
Is it an expected behavior?
postgres= CREATE SEQUENCE s;
CREATE SEQUENCE
Robert Haas wrote:
On Wed, Mar 3, 2010 at 6:28 PM, Bruce Momjian br...@momjian.us wrote:
I whittled my 1.5k open emails down to [five items]
That's a pretty good compression ratio.
It helped that everyone promptly answered my email questions asking for
status, so it wasn't as hard as it
It looks like for me the bottom half of the DefineOpFamily() is
a block copied and pasted from CreateOpFamily().
It has identical logic, variable names and source code comments.
Perhaps, we can replace this code block by CreateOpFamily() call.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
It's been almost three months since our last minor releases, and we've
accumulated enough fixes to justify a new set of updates. The core team
is planning to wrap new tarballs next Thursday for release Monday 3/15.
If you've got any pending back-branch fixes, get 'em in soon.
43 matches
Mail list logo
