On 12.01.2011 06:21, Fujii Masao wrote:
On Sat, Dec 25, 2010 at 2:09 PM, Maxim Boguk 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 PostgreSQL 8.4.4).
Very s
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
>>> Seems like either one of these is fairly problematic in that you have to
>>> have some monstrous kluge to get the backup_label file to appear with
>>> the right name i
On Mon, Jan 10, 2011 at 11:09 PM, Magnus Hagander 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 backup, WalSndWake
On Wed, Jan 12, 2011 at 15:21, Peter Eisentraut 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:
http://postgre
2011/1/12 Florian Pflug :
> 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:
https://github.com/gluefinanc
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 r
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 chec
On Tue, Jan 11, 2011 at 09:41:35PM -0500, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch 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 wrote:
> >> > This begins the patch series for the design I recently p
On Wed, Jan 12, 2011 at 20:18, Pavel Stehule 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 type of array1 is s
2011/1/12 Itagaki Takahiro :
> On Wed, Jan 12, 2011 at 20:18, Pavel Stehule 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
>
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 synt
2011/1/12 Pavel Stehule :
> 2011/1/12 Itagaki Takahiro :
>> On Wed, Jan 12, 2011 at 20:18, Pavel Stehule 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
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 t
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 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,
> > neglecting to t
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan 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 that. Say
>
2011/1/12 Alvaro Herrera :
> 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 loop” code in pg_dump I
On Wed, Jan 12, 2011 at 8:14 AM, Noah Misch 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
EnterpriseDB: h
Greetings,
Minor enhancement, but a valuable one imv. Hopefully there aren't any
issues with it. :)
Thanks!
Stephen
commit 3cb707aa9f228e629e7127625a76a223751a778b
Author: Stephen Frost
Date: Wed Jan 12 09:17:31 2011 -0500
Add support for logging the current rol
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 beh
On Wed, Jan 12, 2011 at 9:23 AM, Stephen Frost 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 %u and this. You
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 12, 2011 at 9:23 AM, Stephen Frost 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 sure I like
On Wed, Jan 12, 2011 at 10:12 AM, Stephen Frost 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 inline, if possib
On Wed, Sep 15, 2010 at 11:14 PM, Heikki Linnakangas
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 still feel it's too short,
On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
> >>> Seems like either one of these is fairly problematic in that you have to
> >>> have some monstrous
Joel Jacobson 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
regression=# create view v2 a
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 CPU-bo
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 t
On Wed, Jan 12, 2011 at 10:15 AM, David Fetter 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 parallel is on
Heikki Linnakangas 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 parallell
>>
>> That's not actua
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 docum
Robert Haas writes:
> On Wed, Jan 12, 2011 at 10:12 AM, Stephen Frost 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 don't remember saying exactly that eit
On Wed, Jan 12, 2011 at 10:24:31AM -0500, Tom Lane wrote:
> Heikki Linnakangas 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 l
* 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 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 overloading a singl
Ron Mayer 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
> production and will
* 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 w
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() a
On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost 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, let's paint it
On Wed, Jan 12, 2011 at 2:16 AM, Martijn van Oosterhout
wrote:
> On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
>> commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
>> Author: Tom Lane
>> Date: Sun May 1 18:56:19 2005 +
>>
>> Change CREATE TYPE to require datatype output and
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 up
Robert Haas writes:
> On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost 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 the elog output
path. Quite aside
On Wed, Jan 12, 2011 at 11:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 12, 2011 at 11:00 AM, Stephen Frost wrote:
>>> +1 for whatever the committer wants to commit. ;)
>
>> OK, done. :-)
>
> Uh, did you actually stop to *think* about this patch?
You have a valid point here, but
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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 awkward, and this
* 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 for)
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,
* 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 horr
On Wed, Jan 12, 2011 at 12:13 PM, Stephen Frost 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.
>
> I had b
2011/1/12 Robert Haas
> On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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 we
On Wed, Jan 12, 2011 at 12:25 PM, Stephen Frost 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 (pgsql-hackers@postgresql.org)
To mak
2011/1/12 Tom Lane :
> 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 into
implemen
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 12, 2011 at 12:25 PM, Stephen Frost 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! ;)
Stephen
*
Robert Haas wrote:
> On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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 un
* 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 loo
Joel Jacobson writes:
> 2011/1/12 Tom Lane :
>> 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 eve
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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
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" the
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
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 pgsq
On Wed, Jan 12, 2011 at 1:12 PM, Bruce Momjian 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 think it e
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:
htt
On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost 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 know which r
On Wed, Jan 12, 2011 at 2:06 PM, Joel Jacobson 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! :-) :-) :-)
Hey, guys, I think it worked...!
--
Robert Haas
EnterpriseDB: http://www.enter
Anssi Kääriäinen 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
should specify READ ON
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 prev
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin 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? If we're going to
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 a
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_depe
On Wed, Jan 12, 2011 at 12:22:55PM -0700, Alex Hunsaker wrote:
> On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin 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
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 existi
Alvaro Herrera 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 casts.
> For example, see
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 :
> > 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, but it might
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
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane wrote:
> Alvaro Herrera 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 wa
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
Robert Haas writes:
> On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane 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 function. The latter point tends to
>>
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
On Wed, Jan 12, 2011 at 2:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane 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
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).
(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 wrote:
> On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
>> 2011/1/12 Tom Lane :
>>> I've sometimes
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 th
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,
> >> d
Peter Eisentraut 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 objects of another
On ons, 2011-01-12 at 12:04 -0500, Robert Haas wrote:
> On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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 o
Alexey Klyukin 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, let's not force them to
On 01/12/2011 04:22 PM, Tom Lane wrote:
Alexey Klyukin 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 upg
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 op
On Wed, Jan 12, 2011 at 4:45 PM, Andrew Dunstan 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'
>> code because
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 techn
Anssi Kääriäinen 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 predicate lock held b
Tom,
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
> "David E. Wheeler" 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 plan t
"David E. Wheeler" 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: function
> ginarr
Dimitri Fontaine writes:
> Peter Eisentraut 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 extension, IMO. If there's somet
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 curr
Andreas Karlsson 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 be inferred fro
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost 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* annoying.
>
"David E. Wheeler" 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
