On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
> So I'm thinking to change pg_last_xlog_receive_location not to
> move backwards.
The attached patch does that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
receive_location_not_back_of
On Wed, Jan 12, 2011 at 14:45, Andrew Dunstan 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.
I can't see how it would break, unless we did it wrong...
> If I'm wrong about th
Hello,
Today I was reading a blog post from a fellow coworker
http://www.depesz.com/index.php/2010/12/11/waiting-for-9-1-knngist/ and
started to mess around with the trigram contrib package for postgres and
playing with some different word dictionaries for English and German. I was
wanting t
Hi,
In the case where there are multiple standbys, when a failover
happens, we usually calculate most advanced standby by using
pg_last_xlog_receive_location or pg_last_xlog_replay_location,
and promote it to new master. The problem is that neither
function might return the right last location of
>>> That doesn't sound right to me. I'd have thought something in class 40.
>>
>> What about:
>>
>> 40004 CONFLICT WITH RECOVERY conflict_with_recovery
>
> We should respect the following convention, from errcodes.h:
>
> * The convention is that new error codes defined by PostgreSQL in a
> * c
On Wed, Jan 12, 2011 at 22:12, Tom Lane wrote:
> "David E. Wheeler" writes:
>> 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
>> I also think wiki page allows us to brush up the documentation
>> rather than exchanging patches effectively. I'll set up a wiki page
>> that contains same contents with *.sgml file to revise documentation
>> stuff to be included into the *.sgml file finally. How about this idea?
>
> Sounds good
Hitoshi Harada writes:
> 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.
I'm not too impressed with this
"David E. Wheeler" writes:
> 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 inter
On Thu, Jan 13, 2011 at 11:29 AM, Itagaki Takahiro
wrote:
> On Thu, Jan 13, 2011 at 00:14, Fujii Masao wrote:
>>> pg_ctl failover ? At the moment, the location of the trigger file is
>>> configurable, but if we accept a constant location like "$PGDATA/failover"
>>> pg_ctl could do the whole thing
"David E. Wheeler" writes:
> 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
>> you have some code that does a ref test on the argument, for example. The
>> behavior would now be changed.
> I think that'd be pretty
On Wed, Dec 29, 2010 at 5:51 PM, Heikki Linnakangas
wrote:
> On 29.12.2010 10:36, Magnus Hagander wrote:
>>
>> On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
>>>
>>> Although maybe now that we've made recovery.conf use the GUC lexer we
>>> oughta continue in that vein and expose those paramet
On 01/12/2011 09:52 PM, Itagaki Takahiro wrote:
On Wed, Jan 12, 2011 at 08:06, Peter Eisentraut wrote:
Is it a good idea that we run make check with MULTIBYTE = SQL_ASCII by
default? We run it with the user's locale by default, so shouldn't we
use the encoding that belongs to the locale by d
Srini Raghavan wrote:
> Thank you very much for reviewing, appreciate the feedback.? As pointed out
> by
> you, it is always best to test it out with the latest version, so, I tested
> the
> same approach with postgres 9.0.2 on windows just now, and it works!
>
>
> I forgot to mention earlie
On Wed, Jan 12, 2011 at 08:06, Peter Eisentraut wrote:
> Is it a good idea that we run make check with MULTIBYTE = SQL_ASCII by
> default? We run it with the user's locale by default, so shouldn't we
> use the encoding that belongs to the locale by default? Otherwise we
> are testing a fairly un
On Thu, Jan 13, 2011 at 00:14, Fujii Masao wrote:
>> pg_ctl failover ? At the moment, the location of the trigger file is
>> configurable, but if we accept a constant location like "$PGDATA/failover"
>> pg_ctl could do the whole thing, create the file and send signal. pg_ctl on
>> Window already k
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I understand. But doing this right is going to take more than ten lines
>> of code, and more than a negligible performance penalty. We have to
>> consider whether it's worth it.
> It'd be ideal if the performance hit could only b
Robert Haas wrote:
> 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 u
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I understand. But doing this right is going to take more than ten lines
> of code, and more than a negligible performance penalty. We have to
> consider whether it's worth it.
It'd be ideal if the performance hit could only be felt by people who
want to e
On Wed, Jan 12, 2011 at 23:29, Alvaro Herrera
wrote:
> Two small nitpicks:
> + check_concatinatable(Oid element_type1, Oid element_type2)
> + ereport(ERROR,
> + (errcode(ERRCODE_DATATYPE_MISMATCH),
> + errmsg("cannot concatenate incompatible arrays"),
> +
Stephen Frost writes:
> Guess I'm just trying to say that I didn't write this patch as an
> academic exercise but rather because it solves a real world problem for
> me.
I understand. But doing this right is going to take more than ten lines
of code, and more than a negligible performance penalt
* Stephen Frost (sfr...@snowman.net) wrote:
> Erm, really? Ok, fine, maybe you didn't have log_line_prefix set
> correctly the first time you needed the information, but after you
> discover that you *don't know*, you're going to be looking for an option
> to let you get that information for the f
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > It might be possible to do and answer that specific question- but what
> > about the obvious next question: which role was this command run with?
> > iow, if I log dml, how do I know what the role was when the dml
> > statement was
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Interesting. I wonder if we shouldn't try to fix this by including
>> the relevant role name in the error message. Or is that just going to
>> be too messy to live?
> It might be possible to do and answer that specific ques
"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 :-)
* 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.
>
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
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
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
"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
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
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
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
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
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 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
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 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
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
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
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
(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 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).
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 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
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
>>
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
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
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 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
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
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 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
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 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 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
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
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
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
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
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
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 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
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 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
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
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
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
* 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
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:
> 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
*
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
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 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: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
* 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 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:
> 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 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
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
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
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
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
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
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
* 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
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
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
* 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: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
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
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
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
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
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 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
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 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
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: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
1 - 100 of 124 matches
Mail list logo
