On 12.01.2011 06:21, Fujii Masao wrote:
On Sat, Dec 25, 2010 at 2:09 PM, Maxim Bogukmaxim.bo...@gmail.com wrote:
While I trying create reproducible test case for BUG #5798 I
encountered very strange effect on two of my servers (both servers
have same hardware platform/OS (freebsd 7.2) and
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Jan 11, 2011 at 19:51, Tom Lane t...@sss.pgh.pa.us wrote:
Seems like either one of these is fairly problematic in that you have to
have some monstrous kluge to get the
On Mon, Jan 10, 2011 at 11:09 PM, Magnus Hagander mag...@hagander.net wrote:
I've committed the backend side of this, without that. Still working
on the client, and on cleaning up Heikki's patch for grammar/parser
support.
Great work!
I have some comments:
While walsender is sending a base
On Wed, Jan 12, 2011 at 15:21, Peter Eisentraut pete...@gmx.net wrote:
You may want to read this thread about the cardinality function are you
trying to add:
http://archives.postgresql.org/pgsql-hackers/2009-02/msg01388.php
Since our archive is split per month, this might be more readable:
2011/1/12 Florian Pflug f...@phlo.org:
I suggest you try to node-folding strategy and see how far it gets you.
Good suggestion! :-) That's exactly what I've been trying to do, but
failed miserably :-(
I have written a thorough description of my problem and put it on my github:
Dear hackers :) Could you look at this thread from General.
---
I say the backend if you have one row type output result treats it as
the full output result, it's really bad if you use STRUCT types (in your
example you see few columns, but this should be one column!). I think
backend should
Hello
there is one issue - probably useless checking a type equality in
function check_comparable and check_concatinatable, because when your
function is registrated with arguments (anyarray, anyarray), then is
guaranteed so type of array1 is same as type of array2, and then you
don't need to
On Tue, Jan 11, 2011 at 09:41:35PM -0500, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Jan 11, 2011 at 06:37:33AM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 4:59 PM, Noah Misch n...@leadboat.com wrote:
This begins the patch series
On Wed, Jan 12, 2011 at 20:18, Pavel Stehule pavel.steh...@gmail.com wrote:
there is one issue - probably useless checking a type equality in
function check_comparable and check_concatinatable, because when your
function is registrated with arguments (anyarray, anyarray), then is
guaranteed so
2011/1/12 Itagaki Takahiro itagaki.takah...@gmail.com:
On Wed, Jan 12, 2011 at 20:18, Pavel Stehule pavel.steh...@gmail.com wrote:
there is one issue - probably useless checking a type equality in
function check_comparable and check_concatinatable, because when your
function is registrated
Attached are WIP version of patches for FDW API. Basically not
changed from last version but rebased to current HEAD.
To make review easier, I split core functionality into 3 patches.
Please apply these patches in the following order.
1) fdw_handler - this patch adds HANDLER option to both
2011/1/12 Pavel Stehule pavel.steh...@gmail.com:
2011/1/12 Itagaki Takahiro itagaki.takah...@gmail.com:
On Wed, Jan 12, 2011 at 20:18, Pavel Stehule pavel.steh...@gmail.com wrote:
there is one issue - probably useless checking a type equality in
function check_comparable and
On Tue, Jan 11, 2011 at 12:34:44PM -0600, Kevin Grittner wrote:
Agreed; but I am starting to get concerned about whether this
particular area can be completed by the start of the CF. I might
run a few days over on 2PC support. Unless ... Dan? Could you look
into this while I chase down the
Excerpts from Joel Jacobson's message of mié ene 12 07:07:35 -0300 2011:
The automatically created objects, such as primary key indexes,
constraints and triggers, have been ignored in this graph, as they are
implicitly created when creating the base objects.
FWIW this idea fails when you
On Jan 12, 2011, at 1:07 AM, David E. Wheeler wrote:
On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
Hello,
Here's the patch that improves handling of arrays as pl/perl function input
arguments, converting postgres arrays of arbitrary dimensions into perl array
references.
On Tue, Jan 11, 2011 at 10:03:11PM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 5:00 PM, Noah Misch n...@leadboat.com wrote:
When ALTER TABLE rewrites a table, it reindexes, but the reindex does not
revalidate UNIQUE/EXCLUDE constraints. ?This behaves badly in cases like
this,
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing
2011/1/12 Alvaro Herrera alvhe...@commandprompt.com:
FWIW this idea fails when you consider stuff such as circular foreign
keys (and I suppose there are other, more common cases). If you really
want something general you need to break those apart. (This is the
explanation for the “break the
On Wed, Jan 12, 2011 at 8:14 AM, Noah Misch n...@leadboat.com wrote:
Something like the attached?
I haven't really analyzed in this detail, but yes, approximately
something sorta like that.
Also, you need to start adding these patches to the CF app.
Done for all.
Thanks.
--
Robert Haas
Greetings,
Minor enhancement, but a valuable one imv. Hopefully there aren't any
issues with it. :)
Thanks!
Stephen
commit 3cb707aa9f228e629e7127625a76a223751a778b
Author: Stephen Frost sfr...@snowman.net
Date: Wed Jan 12 09:17:31 2011 -0500
Add support for
Excerpts from Itagaki Takahiro's message of mié ene 12 01:52:12 -0300 2011:
Separate patches for src and doc attached. It includes a few bug fixes
and cleanup. I changed the error code in trim_array() to
ERRCODE_ARRAY_ELEMENT_ERROR according to the spec.
Two small nitpicks:
+ static void
+
Josh Berkus wrote:
Mainly, that it's not clear we need it. Nobody's pointed to a concrete
failure mechanism that makes it necessary for an existing app to run
under fake-SERIALIZABLE mode.
I think it's quite possible that you're right, and nobody depends on
current SERIALIZABLE behavior
On Wed, Jan 12, 2011 at 9:23 AM, Stephen Frost sfr...@snowman.net wrote:
Minor enhancement, but a valuable one imv. Hopefully there aren't any
issues with it. :)
1. Why %o? That's not obviously mnemonic. Perhaps %U?
2. It won't be clear to people reading this what the difference is
between
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jan 12, 2011 at 9:23 AM, Stephen Frost sfr...@snowman.net wrote:
Minor enhancement, but a valuable one imv. Hopefully there aren't any
issues with it. :)
1. Why %o? That's not obviously mnemonic. Perhaps %U?
r was taken? :) I'm not
On Wed, Jan 12, 2011 at 10:12 AM, Stephen Frost sfr...@snowman.net wrote:
r was taken? :) I'm not sure I like %U, but in the end I don't *really*
care. I'll update it to %U and wait for someone else to complain.
The joys of community...
3. Please attach the patch rather than including it
On Wed, Sep 15, 2010 at 11:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15/09/10 16:55, Tom Lane wrote:
So I'm wondering if we couldn't eliminate the five-second sleep
requirement here too. It's problematic anyhow, since somebody looking
for energy efficiency will
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Jan 11, 2011 at 19:51, Tom Lane t...@sss.pgh.pa.us wrote:
Seems like either one of these is fairly problematic
Joel Jacobson j...@gluefinance.com writes:
Also, circular dependencies seems impossible for some object classes,
such as functions, views, constraints and triggers.
regression=# create table tt(f1 int, f2 int);
CREATE TABLE
regression=# create view v1 as select * from tt;
CREATE VIEW
On 12.01.2011 17:15, David Fetter wrote:
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
Considering that parallell base backups would be io-bound (or
network-bound), there is little need to actually run them in parallell
That's not actually true. Backups at the moment are
On Wed, Jan 12, 2011 at 05:17:38PM +0200, Heikki Linnakangas wrote:
On 12.01.2011 17:15, David Fetter wrote:
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
Considering that parallell base backups would be io-bound (or
network-bound), there is little need to actually run them in
On Wed, Jan 12, 2011 at 10:15 AM, David Fetter da...@fetter.org wrote:
Considering that parallell base backups would be io-bound (or
network-bound), there is little need to actually run them in parallell
That's not actually true. Backups at the moment are CPU-bound, and
running them in
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 12.01.2011 17:15, David Fetter wrote:
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
Considering that parallell base backups would be io-bound (or
network-bound), there is little need to actually run them in
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
1. Why %o? That's not obviously mnemonic. Perhaps %U?
2. It won't be clear to people reading this what the difference is
between %u and this. You probably need to reword the documentation
for the existing option as well as
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 10:12 AM, Stephen Frost sfr...@snowman.net wrote:
Hrm, I could have sworn that Tom had asked for the exact opposite in the
past, but either way is fine by me.
Really? I don't remember that, but it's certainly possible.
I
On Wed, Jan 12, 2011 at 10:24:31AM -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 12.01.2011 17:15, David Fetter wrote:
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
Considering that parallell base backups would be io-bound (or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
+1 for choosing something more mnemonic than %o, btw.
Alright, not to be *too* ridiculous about this, but I'm feeling like
'%R' might be better than '%U', if we don't mind overloading a single
letter based on case. I've always been annoyed at the lack of
On Wed, Jan 12, 2011 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
+1 for choosing something more mnemonic than %o, btw.
Alright, not to be *too* ridiculous about this, but I'm feeling like
'%R' might be better than '%U', if we don't mind
Ron Mayer rm...@cheapcomplexdevices.com wrote:
That Survey's missing one important distinction for that
discussion.
Do you take the the current survey answer
Yes, we depend on it for production code
to imply
Yes, we depend on actual real SERIALIZABLE transactions in
* Robert Haas (robertmh...@gmail.com) wrote:
I was thinking that %u/%U would have the advantage of implying some
connection between the two things which is in fact present. %r/%R
seems not quite as good to me. Also, let's paint it tangerine.
I figured that's where you were going.
+1 for
I found a crash case (assertion failure) when runing psql -f
utf8_encoded_script.sql against client_encoding = shift_jis in
postgresql.conf. Though encoding mismatch is obviously user's fault, a
crash doesn't explain anything to him.
The thing is, prepare_buffer() in psqlscan.l assumes PQmblen()
On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
I was thinking that %u/%U would have the advantage of implying some
connection between the two things which is in fact present. %r/%R
seems not quite as good to me. Also,
On Wed, Jan 12, 2011 at 2:16 AM, Martijn van Oosterhout
klep...@svana.org wrote:
On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
Author: Tom Lane t...@sss.pgh.pa.us
Date: Sun May 1 18:56:19 2005 +
Change CREATE TYPE to
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places our libpq documentation that were unclear
or awkward, and this diff generated by me attempts to address them.
I have already
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost sfr...@snowman.net wrote:
+1 for whatever the committer wants to commit. ;)
OK, done. :-)
Uh, did you actually stop to *think* about this patch?
What you have just committed puts a syscache lookup into
On Wed, Jan 12, 2011 at 11:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost sfr...@snowman.net wrote:
+1 for whatever the committer wants to commit. ;)
OK, done. :-)
Uh, did you actually stop to *think*
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places our libpq documentation that were unclear
or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Uh, did you actually stop to *think* about this patch?
Actually, I was worried about exactly that, but I didn't see anything at
the top of elog.c that indicated if it'd be a problem or not (and the
Syscache lookup issue was *exactly* what I was looking
On Tue, 2011-01-11 at 11:13 -0800, David Fetter wrote:
3. Typmod -- There is still one annoyance about typmod remaining. I need
to treat it like an array in find_typmod_coercion_function(), and then
create a coercion expression. Is it worth it? Would typmod on a range be
confusing, or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What you have just committed puts a syscache lookup into the elog output
path. Quite aside from the likely performance hit, this will
malfunction badly in any case where we're trying to log from an aborted
transaction.
Attached is my (admittedly
On Wed, Jan 12, 2011 at 12:13 PM, Stephen Frost sfr...@snowman.net wrote:
What you have just committed puts a syscache lookup into the elog output
path. Quite aside from the likely performance hit, this will
malfunction badly in any case where we're trying to log from an aborted
transaction.
2011/1/12 Robert Haas robertmh...@gmail.com
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places
On Wed, Jan 12, 2011 at 12:25 PM, Stephen Frost sfr...@snowman.net wrote:
Attached is ...
I don't see an attachment, other than signature.asc.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
2011/1/12 Tom Lane t...@sss.pgh.pa.us:
This isn't particularly *useful*, maybe, but it's hardly impossible.
And if we analyzed function dependencies in any detail, circular
dependencies among functions would be possible (and useful).
Thanks Tom for clarifying, this makes me even more motivated
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jan 12, 2011 at 12:25 PM, Stephen Frost sfr...@snowman.net wrote:
Attached is ...
I don't see an attachment, other than signature.asc.
I suck, sorry about that, here it is..
See, inlining is better! I wouldn't have forgotten it! ;)
Robert Haas wrote:
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places our libpq documentation that
* Robert Haas (robertmh...@gmail.com) wrote:
Logging the OID seems to be of questionable value.
I certainly disagree about this, not being able to figure out what's
causing a 'permissions denied' error because you don't know which role
the log is coming from is *very* annoying. Having to go
Joel Jacobson j...@gluefinance.com writes:
2011/1/12 Tom Lane t...@sss.pgh.pa.us:
This isn't particularly *useful*, maybe, but it's hardly impossible.
And if we analyzed function dependencies in any detail, circular
dependencies among functions would be possible (and useful).
Thanks Tom for
Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places
Kevin,
I think you overestimate what we can meaninfully put in a tiny
radio-button survey.
I'm only trying to get a straw poll idea of whether we have lots of
people using SERIALIZABLE mode *at all*, or (as I suspect) almost none.
If we get 5% or respondees saying we use it in production then
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
I haven't considered that (lack of extensive perlgus-foo) although I think
that's an interesting idea. One drawback would be
On Jan 12, 2011, at 8:48 AM, Robert Haas wrote:
I guess that begs the question of why we need to allow users to call
type output functions directly.
I've used them quite a lot in the past; less so on 8.4+ where casting
everything to text became a lot easier.
Best,
David
--
Sent via
On Wed, Jan 12, 2011 at 1:12 PM, Bruce Momjian br...@momjian.us wrote:
OK, that last part seems kind of vague. ;-) Can you hack up the diff
to have just the changes you think are worthwhile? You can just remove
the parts of the diff you don't like.
Robert, here is a unified diff, which I
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It used to be the case that that was the only way to run certain casts.
For example, see the pre-8.2 version of this:
On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Logging the OID seems to be of questionable value.
I certainly disagree about this, not being able to figure out what's
causing a 'permissions denied' error because you don't
On Wed, Jan 12, 2011 at 2:06 PM, Joel Jacobson j...@gluefinance.com wrote:
Tom, you are a genious! No, seriously, I mean it, this is awesome, it
worked! YES! You totally saved my day! Thank you! Finally! I'm so
happy! :-) :-) :-)
stage whisper
Hey, guys, I think it worked...!
--
Robert Haas
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote:
So, count(*) queries are more than twice as slow compared to the
old serializable transaction isolation level.
I've looked at this enough to know that I can do something about
that, but wanted to point out that this is a good example of why you
I've been looking into Gordon Shannon's crash report here:
http://archives.postgresql.org/pgsql-general/2010-12/msg01030.php
After some groveling around in the core dump (thanks to Gordon for
making that available), I figured out the cause of the problem.
The missing piece of information that
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
By the same token, I'm not convinced it's a good idea for this
behavior to be off by default. Surely many people will altogether
fail to notice that it's an option?
On Jan 12, 2011, at 11:22 AM, Alex Hunsaker wrote:
Personally, I think the point of a compatibility GUC is that at some
point in the distant future we can get rid of it. If we default to
the old behavior thats going to be harder to do. +1 for defaulting to
the new behavior.
+1
[ Id
Excerpts from Joel Jacobson's message of mié ene 12 16:06:24 -0300 2011:
The query below can both produce a DOT-format graph and a tsort of the
creatable order of objects:
WITH
NewObjectOids AS (
SELECT * FROM pg_depend WHERE deptype 'p'
EXCEPT
SELECT * FROM pg_depend_before
On Wed, Jan 12, 2011 at 12:22:55PM -0700, Alex Hunsaker wrote:
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
By the same token, I'm not convinced it's a good idea for this
behavior to be off by default. Surely
Excerpts from Tom Lane's message of jue ene 06 13:57:11 -0300 2011:
Whilst fooling around with GIN, I have repeatedly observed that doing
make in src/backend/access/gin, followed by make install-bin in
src/backend, fails to rebuild the postgres executable --- it just
installs the existing one.
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It used to be the case that that was the only way to run certain
Excerpts from Alex Hunsaker's message of mié ene 12 16:22:55 -0300 2011:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in minor releases, for example the removal of
Safe.pm) ]
On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
2011/1/12 Tom Lane t...@sss.pgh.pa.us:
I've sometimes found it useful to think of internal dependencies as
acting like normal dependencies pointing in the other direction.
I'm not sure that would do much to solve your problem,
On Jan 12, 2011, at 11:36 AM, Alvaro Herrera wrote:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in minor releases, for example the removal of
Safe.pm) ]
I think the main
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It
Excerpts from David E. Wheeler's message of mié ene 12 16:39:56 -0300 2011:
On Jan 12, 2011, at 11:36 AM, Alvaro Herrera wrote:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The general point is that any out-of-band data transmitted to an output
function has to be trustworthy, and it has to be available at any place
that is going to call the output
On Jan 12, 2011, at 11:51 AM, Alvaro Herrera wrote:
I suspect it'd be quiet, unfortunately, since there are a bazillion ad hoc
implementations of a Perl SQL array parser, and many of them, I suspect,
don't complain if the string doesn't look like an SQL array. They would just
parse a
On Wed, Jan 12, 2011 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The general point is that any out-of-band data transmitted to an output
function has to be trustworthy, and it has
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
Well, neither me (I haven't used much of the guts api there).
I
(sorry for top posting, iPhone + drunk)
pg_depend_before is a select * from pg_depend before creating the test db model
Sent from my iPhone
On 12 jan 2011, at 20:36, David Fetter da...@fetter.org wrote:
On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
2011/1/12 Tom Lane
On Jan 12, 2011, at 9:36 PM, Alvaro Herrera wrote:
Excerpts from Alex Hunsaker's message of mié ene 12 16:22:55 -0300 2011:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in
Excerpts from David E. Wheeler's message of mié ene 12 16:55:17 -0300 2011:
On Jan 12, 2011, at 11:51 AM, Alvaro Herrera wrote:
I suspect it'd be quiet, unfortunately, since there are a bazillion ad hoc
implementations of a Perl SQL array parser, and many of them, I suspect,
don't
Peter Eisentraut pete...@gmx.net writes:
What's a not-to-follow dependency?
In case of extensions the code follows dependencies to walk on all
objects. We already have the problem that an extension depending on
another is not relocatable, because 'ALTER EXTENSION SET SCHEMA' would
walk to
On ons, 2011-01-12 at 12:04 -0500, Robert Haas wrote:
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of
Alexey Klyukin al...@commandprompt.com writes:
Since almost everyone votes for making the new behavior a default option I'm
inclined to do that change, although I'm against throwing out the
compatibility option. There are many other reasons except for PL/Perl for
people to upgrade to 9.1,
On 01/12/2011 04:22 PM, Tom Lane wrote:
Alexey Klyukinal...@commandprompt.com writes:
Since almost everyone votes for making the new behavior a default option I'm
inclined to do that change, although I'm against throwing out the
compatibility option. There are many other reasons except for
Here is a very simple change of the patch to make the output look more
like the syntax of ALTER OPERATOR FAMILY to improve consistency.
Before patch:
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin
With the first version:
function 1 bttextcmp(text,text) of
On Wed, Jan 12, 2011 at 4:45 PM, Andrew Dunstan and...@dunslane.net wrote:
I thought the idea of overloading the string representation to look like
the old style was a cute solution. If we don't have anyone at hand who
knows how to do that, let's find someone who does. Not break our users'
On Jan 12, 2011, at 3:29 PM, Robert Haas wrote:
What I was casting a bit of doubt on upthread was whether or not this would
work without possibly breaking some code, in possibly silent or obscure
ways. If I'm wrong about that, then by all means let's use some perl Magic
(that's a technical
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote:
So, count(*) queries are more than twice as slow compared to the
old serializable transaction isolation level.
I got this down from more than twice the run time to running 33%
longer through remembering the last relation for which a search for
a
Tom,
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
Well, actually, I just committed it. If you want to test, feel free.
Note that right now only the anyarray @ @ operators are genuinely
fixed ... I
David E. Wheeler da...@kineticode.com writes:
Thanks, working on it now. I'm restoring a dump from 8.4, but got these erors:
pg_restore: [archiver (db)] Error from TOC entry 3227; 2616 46485 OPERATOR
CLASS gin__int_ops postgres
pg_restore: [archiver (db)] could not execute query: ERROR:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Peter Eisentraut pete...@gmx.net writes:
What's a not-to-follow dependency?
In case of extensions the code follows dependencies to walk on all
objects.
That seems pretty silly/broken. You should only be touching *direct*
dependencies of the
On Jan 12, 2011, at 4:35 PM, Tom Lane wrote:
Did a signature change or something?
Yeah. I think if you just load up the current contrib/intarray first,
you'll be fine (ignore all the object-already-exists errors).
Oh, from 9.1devel? yeah, okay. Will do that tomorrow (finishing the current
Andreas Karlsson andr...@proxel.se writes:
Here is a very simple change of the patch to make the output look more
like the syntax of ALTER OPERATOR FAMILY to improve consistency.
IMO, what this patch needs is to not output the types unless they are
actually different from the default (which can
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost sfr...@snowman.net wrote:
I certainly disagree about this, not being able to figure out what's
causing a 'permissions denied' error because you don't know which role
the log is coming from is *very*
David E. Wheeler da...@kineticode.com writes:
On Jan 12, 2011, at 4:35 PM, Tom Lane wrote:
No, what we need is a decent extension package manager ;-)
Yeah. Maybe you can do that this weekend? Or, I dunno, while you sleep
tonight?
Supposedly it's in the queue for the upcoming CF :-)
1 - 100 of 124 matches
Mail list logo
