On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
ecmascript 5 is the most recent specification for JavaScript and i
would think that having a DATESTYLE format to simplify
interoperability with JavaScript applications would be highly
desirable.
Note that we haven't got any other datestyles
2010/5/19 Peter Eisentraut pete...@gmx.net:
On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
ecmascript 5 is the most recent specification for JavaScript and i
would think that having a DATESTYLE format to simplify
interoperability with JavaScript applications would be highly
desirable.
Pavel Stehule wrote:
2010/5/19 Peter Eisentraut pete...@gmx.net:
On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
ecmascript 5 is the most recent specification for JavaScript and i
would think that having a DATESTYLE format to simplify
interoperability with JavaScript applications
Fujii Masao írta:
Thanks for your reply!
On Fri, May 14, 2010 at 10:33 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
In your design, the transaction commit on the master waits for its XID
to be read from the XLOG_XACT_COMMIT record and replied by the standby.
Right? This design seems
2010/5/19 Mike Fowler m...@mlfowler.com:
Pavel Stehule wrote:
2010/5/19 Peter Eisentraut pete...@gmx.net:
On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
ecmascript 5 is the most recent specification for JavaScript and i
would think that having a DATESTYLE format to simplify
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 lines, but I don't need a new security
problem. So my proposal is change nothing on this integrated
functionality and
2010/5/19 Mike Fowler m...@mlfowler.com:
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 lines, but I don't need a new security
problem. So my proposal is change
Pavel Stehule wrote:
2010/5/19 Mike Fowler m...@mlfowler.com:
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 lines, but I don't need a new security
2010/5/19 Mike Fowler m...@mlfowler.com:
Pavel Stehule wrote:
2010/5/19 Mike Fowler m...@mlfowler.com:
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100
On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Isn't reading the same WAL twice (by walreceiver and startup process)
inefficient?
Yes, and I didn't implement that because it's inefficient.
So I'd like to propose to use LSN instead of XID since LSN can
be easily
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 19, 2010 at 12:59 PM, Robert Haas robertmh...@gmail.com wrote:
In terms of removing the backup label file, can we simply have an
additional boolean in the postmaster that indicates whether we've ever
reached
Bernd Helmle maili...@oopsware.de writes:
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc wrote:
May I ask whats the reason is for breaking the compatibillity?
Efficency, if i am allowed to call it this way. The new hex
representation should be more efficient to retrieve and to
Robert Haas robertmh...@gmail.com writes:
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yes, but I prefer XLogCtl-SharedRecoveryInProgress, which is the almost
same indicator as the boolean you suggested. Thought?
It feels cleaner and simpler to me to use the
On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yes, but I prefer XLogCtl-SharedRecoveryInProgress, which is the almost
same indicator as the boolean you suggested.
Hi,
I'm going to start work on another XML todo item:
Add XML Schema validation and xmlvalidate function (SQL:2008)
The standard identifies XMLVALIDATE as:
XML validate ::=
XMLVALIDATE left paren
document or content or sequence
XML value expression
[ XML valid according
Fujii Masao írta:
On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Isn't reading the same WAL twice (by walreceiver and startup process)
inefficient?
Yes, and I didn't implement that because it's inefficient.
So I'd like to propose to use LSN
On Wed, May 19, 2010 at 8:49 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yes, but I prefer XLogCtl-SharedRecoveryInProgress,
On 05/19/2010 08:13 AM, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc wrote:
May I ask whats the reason is for breaking the compatibillity?
Efficency, if i am allowed to call it this way. The new hex
representation
On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 05/19/2010 08:13 AM, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc wrote:
May I ask whats the reason is for breaking the
On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 05/19/2010 08:13 AM, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall k...@rice.edu wrote:
On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 05/19/2010 08:13 AM, Tom Lane wrote:
Bernd Helmle
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
given how much faster the new format is (or rather how slow the old one
was) and the number of people I have seen complaining why is bytea so
slow) I would like to see it staying turned on by default. However this
also depends on how
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane g...@turnstep.com wrote:
given how much faster the new format is (or rather how slow the old one
was) and the number of people I have seen complaining why is bytea so
slow) I would like to see it staying turned on by default. However this
On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane g...@turnstep.com
wrote:
given how much faster the new format is (or rather how slow the old one
was) and the number of people I have seen complaining why is
* Magnus Hagander mag...@hagander.net [100519 11:08]:
How do the distros generaly deal with that? E.g. do we have to wait
for RHEL7 for it to actually show up in redhat?
Don't worry, 9.0 won't show up in redhat for a while yet either...
;-)
--
Aidan Van Dyk
On Wed, May 19, 2010 at 11:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane g...@turnstep.com
wrote:
given how much faster the new format is (or rather how slow
On Wed, May 19, 2010 at 09:05, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall k...@rice.edu wrote:
Changing something like that within the minor release arc is
not a good idea. It would be better to have it on by default and
if the driver developers
On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, May 19, 2010 at 09:05, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall k...@rice.edu wrote:
Changing something like that within the minor release arc is
not a good idea.
On 05/19/2010 11:45 AM, Robert Haas wrote:
On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, May 19, 2010 at 09:05, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall k...@rice.edu wrote:
Changing something like that
On 05/19/2010 11:19 AM, Magnus Hagander wrote:
On Wed, May 19, 2010 at 11:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander mag...@hagander.net
wrote:
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane g...@turnstep.com
wrote:
given how
On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
I think it just depends on whether we're likely to get releases from
Linux vendors that include PG 9.0 but not the updated drivers. I'm
not sure their schedule will be affected by whether we call it 8.5 or
On 05/19/2010 12:32 PM, Robert Haas wrote:
On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
I think it just depends on whether we're likely to get releases from
Linux vendors that include PG 9.0 but not the updated drivers. I'm
not sure their schedule
On May 19, 2010, at 18:32 , Robert Haas wrote:
On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
I think it just depends on whether we're likely to get releases from
Linux vendors that include PG 9.0 but not the updated drivers. I'm
not sure their schedule
On 2010-05-18 18:57, Bruce Momjian wrote:
jes...@krogh.cc wrote:
Hi
I tried running pg_upgrade from the current snapshot of postgresql and
upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
in the process and all that came out was only ok's but when I tried a
simple
Magnus Hagander mag...@hagander.net writes:
On Wed, May 19, 2010 at 11:11 AM, Robert Haas robertmh...@gmail.com wrote:
Yeah, that's what I'm worried about. I remember going through this
with E'' quoting. It wasn't fun.
Right. So do we know what the policy is? As long as DBD::Pg is
released
We adding support for Solaris x86 and this pushes us to upgrade the from
the old-old version of Postgres we've been using for years.
(The requirement is to have the 64-bit exec and libs)
I looked at the release notes but could not figure out at which point
Postgres gave the option of building
Hello
How can I determine the pg_class oid of the argument type in a
polymorphic C function when it's called with a table row?
PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
Oid arg_type = get_fn_expr_argtype(fcinfo-flinfo, 0);
elog(ERROR, arg_type %d, arg_type);
On Wed, May 19, 2010 1:31 pm, Tom Lane wrote:
BTW, standard_conforming_strings is really a different case because of
the SQL-injection security hazards with non-scs-aware client code.
I don't see any comparable risk for bytea format.
Yeah, and the impact of this will be much more limited.
BRUSSER Michael michael.brus...@3ds.com writes:
I looked at the release notes but could not figure out at which point
Postgres gave the option of building the 64-bit binaries.
Quite a long time ago. Any reasonably current release should be OK.
One feature that we'll be missing terribly is
Bogdan Vlad bogdancv...@gmail.com writes:
How can I determine the pg_class oid of the argument type in a
polymorphic C function when it's called with a table row?
You're confusing pg_class oid with pg_type oid. The type oid
of the function argument is necessarily going to be a *type* oid.
You
Bruce Momjian wrote:
This is the production system. I have absolutely no indications that
anything should be wrong in there. It has run rock-solid since it got
migrated (dump/restore) to 8.4 for about 7 months now. So I am a bit
scared about you telling that it seems wrong. (but that
Jesper Krogh wrote:
On 2010-05-18 18:57, Bruce Momjian wrote:
jes...@krogh.cc wrote:
Hi
I tried running pg_upgrade from the current snapshot of postgresql and
upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
in the process and all that came out was only
Hi.
I am working on getting full-text-search to work and have
come across something I think look a bit strange.
The document base is arount 350.000 documents and
I have set the statistics target on the tsvector column
to 1000 since the 100 seems way of.
# ANALYZE verbose reference
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
There is quite some confusion going on between using Postgres and
PostgreSQL, I changed that to the later because that is how we spell the
productname in all the other parts
Excerpts from Stefan Kaltenbrunner's message of mié may 19 15:53:18 -0400 2010:
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
Surely this para can be removed?
para
If you are using tablespaces and
Stefan Kaltenbrunner wrote:
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
There is quite some confusion going on between using Postgres and
PostgreSQL, I changed that to the later because that is how we spell the
Alvaro Herrera wrote:
Excerpts from Stefan Kaltenbrunner's message of mi?? may 19 15:53:18 -0400
2010:
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
Surely this para can be removed?
para
If you
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
There are some limitations when migrating from 8.3 to 8.4, but not when
migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you
give a specific example?
Didnt the 'name' alignment change?
Andres
--
Sent via pgsql-hackers
Andres Freund wrote:
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
There are some limitations when migrating from 8.3 to 8.4, but not when
migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you
give a specific example?
Didnt the 'name' alignment change?
Uh, the
On Wed, May 19, 2010 at 10:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 19, 2010 at 8:49 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao
Hajimemashite Takahiro,
Thanks for your feedback.
I applied all the changes on 9.0beta manually and then it compiled without
any assertion failures.
I also changed the oids to a different unused range, since the ones I used
before had been taken in 9.0beta1.
There are still some problems
On Wed, May 19, 2010 at 9:58 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
In the patch, PQputCopyData() checks the newly-introduced pg_conn field
duplexCopy. Instead, how about checking the existing field replication?
I didn't see there was such a new field. (looking...) I can see now,
it
Hi Robert,
Can we get that commitfest renamed? And if I should know how to do
that, can you inform me how?
Thanks!
-selene
--
http://chesnok.com/daily - me
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
53 matches
Mail list logo
