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.
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
pgsql-cleanup-defineopfam
Robert Haas wrote:
> On Wed, Mar 3, 2010 at 6:28 PM, Bruce Momjian 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 sounds.
--
2010/3/3 KaiGai Kohei :
> (2010/03/03 22:42), Robert Haas wrote:
>> 2010/3/3 KaiGai Kohei:
>>> (2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Kohei:
> Is it an expected behavior?
>
> postgres=> CREATE SEQUENCE s;
> CREATE SEQUENCE
> postgres=> ALTER T
On Wed, Mar 3, 2010 at 6:28 PM, Bruce Momjian 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:
http://www.postgresql.org/mai
(2010/03/03 22:42), Robert Haas wrote:
> 2010/3/3 KaiGai Kohei:
>> (2010/03/03 14:26), Robert Haas wrote:
>>> 2010/3/2 KaiGai Kohei:
Is it an expected behavior?
postgres=>CREATE SEQUENCE s;
CREATE SEQUENCE
postgres=>ALTER TABLE s RENAME sequence_name TO abc
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 think
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 a
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:
>
> 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 Momjia
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 nee
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 pr
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
Tom Lane wrote:
> "Kevin Grittner" 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 of values and
Tom Lane wrote:
> Bruce Momjian 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.
>
>
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
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
Bruce Momjian 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 would actually
On 4 March 2010 04:08, Tom Lane wrote:
> Brendan Jurd 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, "Q"Q ' and expect to get the correct answer. If we
>> start throwing
Tom Lane wrote:
> Brendan Jurd 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, "Q"Q ' and expect to get the correct answer. If we
> > start throwing an error on the Q fi
Brendan Jurd 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, "Q"Q ' and expect to get the correct answer. If we
> start throwing an error on the Q field, then users would have
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_d
On 3 March 2010 14:34, Bruce Momjian wrote:
> Scott Bailey wrote:
>> Tom Lane wrote:
>> > Asher Hoskins 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 because it i
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
>
--
P
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 j
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
Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 ;-)
Ah. If it's just
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 in
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> se
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao 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, or the accurate
2010/3/3 KaiGai Kohei :
> (2010/03/03 14:26), Robert Haas wrote:
>> 2010/3/2 KaiGai Kohei:
>>> Is it an expected behavior?
>>>
>>> postgres=> CREATE SEQUENCE s;
>>> CREATE SEQUENCE
>>> postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
>>> ALTER TABLE
>>>
>>> postgres=> CREATE TABL
On Fri, Feb 26, 2010 at 2:34 AM, Josh Berkus 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 recy
On Tue, Feb 23, 2010 at 1:44 PM, Fujii Masao wrote:
> recovery.conf.sample has the following section for Hot Standby.
> Is this still required?
>
>> #---
>> # HOT STANDBY PARAMETERS
>> #
On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao 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 that wrong setting
Magnus Hagander wrote:
2010/3/3 Andrew Dunstan :
Tom Lane wrote:
Andrew Dunstan 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
2010/3/3 Yeb Havinga :
> Pavel Stehule wrote:
>>
>> 2010/3/3 Yeb Havinga :
>>
>>>
>>> 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 forma
Pavel Stehule wrote:
2010/3/3 Yeb Havinga :
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
2010/3/3 Yeb Havinga :
> 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 co
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 va
Hi,
KaiGai Kohei írta:
> (2010/03/03 14:26), Robert Haas wrote:
>
>> 2010/3/2 KaiGai Kohei:
>>
>>> Is it an expected behavior?
>>>
>>> postgres=> CREATE SEQUENCE s;
>>> CREATE SEQUENCE
>>> postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
>>> ALTER TABLE
>>>
>>> postgres=>
2010/3/3 Andrew Dunstan :
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan 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 itself. The onl
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=>
43 matches
Mail list logo
