On Tue, May 13, 2008 at 8:19 AM, Josh Tolley <[EMAIL PROTECTED]> wrote:
> On Tue, May 13, 2008 at 8:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > > On Mon, May 12, 2008 at 11:23:17PM -0600, Josh Tolley wrote:
> > >> SPI_push();
> > >> r
Decibel! <[EMAIL PROTECTED]> writes:
> Not to be a PITA about this, but I reeally think users are going to
> complain if we remove the % replacement stuff... Is there no way to
> keep that with the new syntax?
Uh, I didn't remove anything.
regards, tom lane
--
Sent v
On May 13, 2008, at 11:53 AM, Tom Lane wrote:
So right now I'm thinking I like my original proposal
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php
with the exception that we should go with
SQLSTATE 'xyzzy'
as the syntax in EXCEPTION lists.
Not to be a PITA about this
Alvaro Herrera wrote:
> There's another serious usability problem here, which is that the pager
> ability is not being used correctly. Consider the \df+ tg_* query I
> used as example for another bug report. psql says that it is 27 rows; I
> have my window taller than that (47 lines right now), y
There's another serious usability problem here, which is that the pager
ability is not being used correctly. Consider the \df+ tg_* query I
used as example for another bug report. psql says that it is 27 rows; I
have my window taller than that (47 lines right now), yet the output is
actually *a l
2008/5/13 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> who write this patch?
>
> Well, like I said, I'm willing to adjust the patch to whatever syntax
> we come up with.
>
> After sleeping on it I'm a bit less excited about using the SQL/PSM
> SIGNAL syntax; the re
Shane Ambler wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>> I promised to review our psql \? output to see if I could improve it,
> >>> particularly the "General" section at the top. Below are the results.
> >>>
> >>> Are the new sections ideal, and in the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > The idea would be for the dash to appear outside where normal data
> > appears:
> >
> > internal | RI_FKey_cas-| referential
> > ; cade_del; integrity
> >
> > If we don't allow a dash, I think wrapping on word boundaries wi
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> who write this patch?
Well, like I said, I'm willing to adjust the patch to whatever syntax
we come up with.
After sleeping on it I'm a bit less excited about using the SQL/PSM
SIGNAL syntax; the reason being that if we use that, and then sometime
in
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
I promised to review our psql \? output to see if I could improve it,
particularly the "General" section at the top. Below are the results.
Are the new sections ideal, and in the best ordering? Should \copyright
be kept in "Gene
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think the behaviour would be better if we were able to only break on
> words, and make columns wider on those where words wouldn't fit.
select repeat('xyzzy', 10);
Now admittedly our current handling of this isn't all that great either,
but you c
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> If we're going to check for file length, we should definitely check the
> file length when we write it, so that we fail at PREPARE time, and not
> at COMMIT time.
I think this is mere self-delusion, unfortunately. You can never be
certain at pr
Tom Lane wrote:
Gavin Sherry <[EMAIL PROTECTED]> writes:
There's an apparently arbitary limit of 10,000,000 bytes in twophase.c
on the size of a two phase commit file. I can't see why this limit
exists.
The comment seems perfectly clear about why the limit exists:
* Check file length. W
On Tue, May 13, 2008 at 5:11 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Andrew Dunstan wrote:
>
> > I would be very surprised if xcopy did not exhibit the same
> > preallocating behaviour as copy.
>
> I, on the other hand, would not say anything until someone tried it, and
> then wouldn't
Andrew Dunstan wrote:
> I would be very surprised if xcopy did not exhibit the same
> preallocating behaviour as copy.
I, on the other hand, would not say anything until someone tried it, and
then wouldn't be surprised if it behaved either way :-)
--
Alvaro Herrera
Bruce Momjian wrote:
> The idea would be for the dash to appear outside where normal data
> appears:
>
> internal | RI_FKey_cas-| referential
>; cade_del; integrity
>
> If we don't allow a dash, I think wrapping on word boundaries will be
> impossible because we can't
On May 12, 2008, at 11:53 AM, Tom Lane wrote:
3. I think we should allow the user to specify the error message the
same way as the other options, that is
RAISE level USING MESSAGE = string_expression [ , ... ]
The %-format business has always struck me as a bit weird, and it's
much more s
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Another and probably simpler thing to try would be the GnuWin32 version
of cp. If we can verify that it behaves itself, we should probably
recommend it for use in archive_command instead of the native Windows
copy.
Perhaps use xcopy, w
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> I think we can wrap if there is whitespace within a few characters
> >> before the break point, and use a dash if we have to break a word. Is
> >> that what people want?
>
> > Ugh.
>
> Inserting dashes wou
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I think we can wrap if there is whitespace within a few characters
>> before the break point, and use a dash if we have to break a word. Is
>> that what people want?
> Ugh.
Inserting dashes would be a truly horrid idea: "ab" an
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>
>>> I try to play with lint now if it gets better results.
>>
>> Ok, good.
>
> Hmm, It generates a lot of unnecessary includes in *.c files. I have
> checked only couple of them and it seems that they are really
> unnecessary. A attach output. Un
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I promised to review our psql \? output to see if I could improve it,
> > particularly the "General" section at the top. Below are the results.
> >
> > Are the new sections ideal, and in the best ordering? Should \copyright
> > be kept in "General
Bruce Momjian wrote:
> I promised to review our psql \? output to see if I could improve it,
> particularly the "General" section at the top. Below are the results.
>
> Are the new sections ideal, and in the best ordering? Should \copyright
> be kept in "General" at the top? Should \? be listed
I promised to review our psql \? output to see if I could improve it,
particularly the "General" section at the top. Below are the results.
Are the new sections ideal, and in the best ordering? Should \copyright
be kept in "General" at the top? Should \? be listed?
I also pulled up some descri
Andrew Dunstan wrote:
> Another and probably simpler thing to try would be the GnuWin32 version
> of cp. If we can verify that it behaves itself, we should probably
> recommend it for use in archive_command instead of the native Windows
> copy.
Perhaps use xcopy, which should be more ubiquit
On Tue, May 13, 2008 at 10:34:23AM -0400, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > There's an apparently arbitary limit of 10,000,000 bytes in twophase.c
> > on the size of a two phase commit file. I can't see why this limit
> > exists.
>
> The comment seems perfectly clear a
Bruce Momjian wrote:
> I think we can wrap if there is whitespace within a few characters
> before the break point, and use a dash if we have to break a word. Is
> that what people want?
Ugh.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Gavin Sherry <[EMAIL PROTECTED]> writes:
> There's an apparently arbitary limit of 10,000,000 bytes in twophase.c
> on the size of a two phase commit file. I can't see why this limit
> exists.
The comment seems perfectly clear about why the limit exists:
* Check file length. We can determin
Bryce Nesbitt wrote:
> It's not that hard to do.
>
> I chose not to, when writing the patch, because it makes the result flow
> over many more lines.
> And regardless, it pretty much has to cut long "words", of which there
> are many in typical SQL output.
> And, I hardly ever read actual large
On Tue, May 13, 2008 at 8:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > On Mon, May 12, 2008 at 11:23:17PM -0600, Josh Tolley wrote:
> >> SPI_push();
> >> retval =
> >> InputFunctionCall(&flinfo, lolVarGetString(returnVal, true),
> >> resul
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Right, but I still need the other part of the check, right? This one
> still fails the same check as my patch, no? Because I assume the hole
> you found there was that get_sync_bit() will return 0 for two different
> sync methods as long as none of them
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Mon, May 12, 2008 at 11:23:17PM -0600, Josh Tolley wrote:
>> SPI_push();
>> retval =
>> InputFunctionCall(&flinfo, lolVarGetString(returnVal, true),
>> resultTypeIOParam, -1);
>> SPI_pop();
> Won't this cause the return value to be allocated
Tom Lane wrote:
> I wrote:
> > Okay, but you failed to correctly reproduce the conditions for
> > closing the old file.
>
> A more bulletproof solution might involve passing sync_method to
> get_sync_bit as an explicit parameter, and then the assign hook
> could do
> if (get_sync_bit(sync_me
I wrote:
> Okay, but you failed to correctly reproduce the conditions for closing
> the old file.
A more bulletproof solution might involve passing sync_method to
get_sync_bit as an explicit parameter, and then the assign hook
could do
if (get_sync_bit(sync_method) != get_sync_bit(new_sync
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Since it didn't really sound like a nice option, here's a third one I
> came up with later. Basically, this one splits things apart so we only
> use one variable, which is sync_method. Instead of using a macro to get
> the open sync bit, it uses a fu
I wrote:
However, we should probably make the behaviour switchable. If the
archive_command populating the archive_directory were rsync, for
example, this problem should not occur, because it copies to a temp
file, and then renames it, so we should never see an incomplete file
even though rs
Simon Riggs wrote:
On Tue, 2008-05-13 at 08:42 +0100, Dave Page wrote:
On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
>> Well, the patch was rejected long ago, not sure why its in t
There's an apparently arbitary limit of 10,000,000 bytes in twophase.c
on the size of a two phase commit file. I can't see why this limit
exists.
I hit this limit by creating a prepared transaction which included
dropping a schema with about 25,000 objects in it and then trying to
commit it. The r
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Yeah, I remember those. What needs to be looked at here is *why* the
>>> output is changing. For a patch that allegedly does not touch the
>>> planner, it's fairly disturbing that you don't get the same results.
>
On Tue, 2008-05-13 at 08:42 +0100, Dave Page wrote:
> On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> > > Simon Riggs wrote:
> > >> Well, the patch was rejected long ago, not sure why its in this
> > >> commitfest. But its
On Tue, May 13, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
> > Simon Riggs wrote:
> >> Well, the patch was rejected long ago, not sure why its in this
> >> commitfest. But its an open issue on the Windows port.
>
> > Surely the right fix i
Brendan Jurd wrote:
I really like the idea of wrapping, but after playing with the format
a bit myself, I have to agree with Tom that breaking in the middle of
words produces some very nasty output.
If the format could be improved to only wrap on word boudaries, that
would increase its appeal d
42 matches
Mail list logo
