Hello again,
I received the following email from a helpful fellow off-list,
pointing out an error in my review:
On Fri, Sep 5, 2008 at 7:03 PM, Ragnar [EMAIL PROTECTED] wrote:
On fös, 2008-09-05 at 15:07 +1000, Brendan Jurd wrote:
Wouldn't this be better written
On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
* the way you had it set up, the CREATE OR REPLACE FUNCTION command
would be sent to the backend instantaneously upon return from the
editor, with no opportunity for the user to decide he didn't want his
changes applied. This
On Fri, Sep 5, 2008 at 6:54 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
Please volunteer now!
Everybody is stuck in I'm not good enough to do a full review. They're
right (myself included), so that just means we're organising it wrongly.
We
On Tue, Aug 19, 2008 at 12:24 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Ok, I rewrote the patch to use SIGALRM instead of gettimeofday.
Hi Itagaki-san,
Josh assigned your patch to me for an initial review. Here's what I
have so far.
The patch applies cleanly on the latest git HEAD, and
On Wed, Sep 3, 2008 at 3:39 AM, Tom Lane [EMAIL PROTECTED] wrote:
The description of the CommitFestBlank template suggests that it sets up
an editable page for you, but AFAICT it does no such thing. I had to
manually create all the right sections:
On Wed, Sep 3, 2008 at 10:31 AM, Tom Lane [EMAIL PROTECTED] wrote:
It still seems a bit awkward though. AFAICS the sentence about
This is the page for CommitFest starting 2008 November would
have to be inserted after committing the first version of the
page?
Yes, you do have to perform
On Wed, Sep 3, 2008 at 10:55 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I suppose we could introduce an argument to the template, so that you
would call it with {{subst:CommitFestBlank|November 2008}}, but it's
only going to save us one edit. I can add
On Tue, Sep 2, 2008 at 3:31 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
Barring any further comments/objections, I'll go ahead and prepare a
patch to add this to core.
Any opinions on where pg_typeof() should be defined? This function is
a little unusual and doesn't seem to slot nicely into any
On Tue, Sep 2, 2008 at 2:03 PM, David E. Wheeler [EMAIL PROTECTED] wrote:
BTW, anyone have any interest in this function in core? Its purpose is to
return a string identifying the data type of its argument. It's useful for
dynamically building queries to pass to PL/pgSQL's EXECUTE statement
On Tue, Sep 2, 2008 at 2:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Neil Conway [EMAIL PROTECTED] writes:
Returning regtype seems like the natural choice.
I was just about to say the same.
Yes. In fact, the way I typically use the function is to write
gettype(whatever)::regtype. I was too
On Sun, Aug 31, 2008 at 6:18 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm fooling around with getting the parser to report an error cursor
location if input conversion fails for a constant in a SQL command.
...
This seems like it'd be a pretty useful thing to have in long queries,
but in short
On Thu, Aug 28, 2008 at 3:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alternatively, suggest that the email message submitting the patch
mentions that this resolves TODO item so-and-so. Then the committer
would know to go fix the TODO item.
Yes, I've noticed that some submitters are already
On Wed, Aug 27, 2008 at 11:05 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
David Fetter wrote:
For example, Common Table Expressions is both on the TODO list and on
September's Commitfest. They should probably point to each other so
long as such a relationship exists.
(Actually what this
On Wed, Aug 27, 2008 at 2:48 AM, Tom Lane [EMAIL PROTECTED] wrote:
Certainly true. Okay, let's leave it alone for a little while and see
if the growth curve flattens out. It'll certainly be easiest to manage
if it can stay a single page.
Apart from the management aspect (which is very much
On Wed, Aug 27, 2008 at 3:31 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
The size of the page really isn't something we should be worrying
about. As Greg points out, we have the usual wiki per-section edit
capability, so in practice we will almost never need
On Wed, Aug 27, 2008 at 4:23 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Goodness, if only we had some kind of organized repository for these TODO
items capable of holding multiple categories per item. Maybe something with
items and attributes, and some kind of relationship between the TODO item
On Fri, Aug 22, 2008 at 10:10 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Alvaro Herrera escribió:
They did not merge with the text, but they were not searchable. May I
suggest using the text [easy] and [done] instead? That way, it is
searchable, and they don't merge with the text.
I just
On Tue, Jul 8, 2008 at 3:33 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Hmmm. I thought that commitfest-by-wiki was something that we were only
doing until we had the technical requirements for tracking commitfests
nailed down, and then we were going to write a PHP app. No?
That sounds good to
On Sun, Jul 6, 2008 at 11:44 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Just a personal request, but I would like a permanent URL that points to
the in-progress commit page and is only changed when the commit fest of
_over_.
Well, most of the time there isn't any commitfest in-progress at
On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt [EMAIL PROTECTED] wrote:
Tom Lane wrote:
After experimenting for a bit, I'd say never. This output format is
extremely ugly. Maybe if it had enough smarts not to break in the
middle of words ...
regards, tom lane
Yet, wrapped is the same
On Tue, May 13, 2008 at 2:53 AM, Tom Lane [EMAIL PROTECTED] wrote:
1. The parentheses around the USING list seem useless; let's drop 'em.
Yes.
2. I think the separation between SQLSTATE and CONDITION is just
complication. A SQLSTATE is required to be exactly 5 digits and/or
upper case
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default. I think psql \df and \dT
certainly can benefit from wrapped mode. \df+ even displays, though
there is
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I for one would definitely like backslash commands with very wide
output to be wrapped by default.
(At least) one place where I would not like it is in \df+, because
wrapped function output would
On Sat, May 10, 2008 at 2:49 PM, Tom Lane [EMAIL PROTECTED] wrote:
I see that Brendan has proposed the following definition on
CommitFest:Help:
I wouldn't say I did anything so formal as proposing a definition =)
Someone mentioned that a column to indicate who's handling each patch
would be
On Thu, May 8, 2008 at 12:17 AM, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it would be helpful for us to provide an infrastructure where
people who don't run their own servers to store their patches at a
stable URL where they can keep updating the
On Thu, May 8, 2008 at 1:54 AM, Matthew T. O'connor [EMAIL PROTECTED] wrote:
Patches are an integral part of the conversation about development,
I'd go further than that. Patches ARE conversation about development,
they are just in C rather than English.
Having one list for the parts of the
On Tue, Apr 29, 2008 at 7:00 AM, PFC [EMAIL PROTECTED] wrote:
I have found that the little bit of code posted afterwards did eliminate
SQL holes in my PHP applications with zero developer pain, actually it is
MORE convenient to use than randomly pasting strings into queries.
You just call
iD8DBQFIFOAe5YBsbHkuyV0RAjHtAJ41opoNgu8M4jYTz9wsR2YGQNnDJQCgqNM0
RKNzCRnHUFwyNjSB3O3k0c8=
=andX
-END PGP SIGNATURE-
On Wed, Jul 18, 2007 at 10:00 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
On 7/18/07, Tom Lane [EMAIL PROTECTED] wrote:
This is all good but I think that self-inconsistent format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:13 PM, Andrew Dunstan wrote:
Before you come trolling on this (or any other) subject, please read the
voluminous debates that have taken place about it. Apparently you think it's
something we have never considered,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 5:08 PM, Bryce Nesbitt
wrote:
Well, come to think of it, wrapped is not really a new output format in
the sense of html or latex. It could build on aligned:
\pset format aligned [autowrap|nowrap|nnn]
I agree that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:27 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Log Message:
---
Update:
* Allow adding/removing enumerated values to an existing enumerated data
Where did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:46 AM, Gregory Stark wrote:
If you specify format=wrapped and get something other than wrapped it's a bug
and people will undoubtedly report it as such.
Agree. If I tell psql that I want wrapped output and it gives me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:02 AM, Tom Lane wrote:
Brendan Jurd writes:
Has anyone had a close look at how hard it would be allow just the
add to the end capability?
The problem is you can't guarantee anything about the ordering of the
new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 5:21 AM, Bruce Momjian
wrote:
Obviously you have expections of how wrapping should behave. Please
name me an application that has a wrapped mode that has the output to a
file wrap based on the screen width? It isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:19 AM, Tom Dunstan wrote:
I wonder if it's worth revisiting the decision to save enums on disk
as oids. The very first idea that I had was to have an enum value as
the combination of both an enum id and the ordinal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
One scenario I'm not happy about is this: the friendly db admin has
happily added an extra value to the end before and the operation has
been a snap - no rewriting required. But this time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 11:02 AM, stephen layland wrote:
I've written a quick patch against the head branch (8.4DEV, but it also
works with 8.1.3 sources) to fix LDAP authentication support to
work with LDAPS servers that do not need start TLS.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 24, 2008 at 7:13 PM, Richard Huxton wrote:
Kaloyan Iliev wrote:
r=# CREATE TABLE test( a text, b int);
CREATE TABLE
r=# INSERT INTO test VALUES ('test',1);
INSERT 0 1
r=# ALTER TABLE test ADD COLUMN id INT NOT NULL PRIMARY
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 25, 2008 at 2:27 AM, Tom Lane wrote:
Brendan Jurd writes:
transformIndexConstraint sets the is_not_null flag on the ColumnDefs
associated with the primary key. That works great in a CREATE TABLE
context, but in ADD COLUMN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 25, 2008 at 3:46 AM, Tom Lane wrote:
alter table t1 add column f2 int not null;
transformAlterTableStmt will produce an AT_AddColumn subcommand
containing a ColumnDef with is_not_null = false, followed by an
AT_SetNotNull
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 24, 2008 at 8:30 AM, Bruce Momjian
wrote:
I have moved this discussion to hackers in hopes of getting more
feedback, and moved the patch to a static URL:
Hi Bruce,
This is a very cool feature! Looking through the patch I did have a
On Wed, Apr 23, 2008 at 2:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least, this
occured to me as i accidently removed entries done by Laurenz
On Wed, Apr 23, 2008 at 12:16 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Perhaps what's going on is that the software does not check that the
version I read is the most recent one :-( so if two of us edit the page
at the same time, the one committing last is going to stomp on the
changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 9:28 AM, Joshua D. Drake wrote:
Why do we care, if the version matches? Not that I am feeling like
fighting about it but it seems just a waste of bytes. It makes sense if
the version doesn't match.
To take a field
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 10:11 AM, Joshua D. Drake wrote:
On Wed, 23 Apr 2008 10:07:46 +1000
Brendan Jurd wrote:
In such an environment, it's *very* useful to have instant feedback on
which server I've just connected to with psql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 10:37 AM, Joshua D. Drake wrote:
Sure. What did you think about Andrew's suggestion?
I think it's cool; allowing the version to be added to a custom psql
prompt is a nice feature, regardless of how we go with the banner.
On Mon, Apr 21, 2008 at 11:54 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
I did notice that the section on vim settings doesn't mention anything
about the expandtab setting. Ideally this should be set to
noexpandtab (noet) to preserve tab spacing. I'll add it to the wiki
page, but feel
On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
people think about that one, and
put a certain amount of effort on it. Credit for the
templating system goes to Brendan Jurd, who implemented the way to make
it display as tables but without the messy markup. I think the
templates that are now in place make for a reasonably comfortable
environment. Not as simple
On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in 2009/2010
On Tue, Apr 22, 2008 at 2:44 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Why not use a form for posting new patches that would automatically put it
on the right page? (I have no idea if you can do that sort of thing using
mediawiki - it's just what I would do if I were designing a patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote:
Peter Eisentraut writes:
Around it
was proposed to truncate the psql welcome screen. What do you think about
that?
Personally. I'm very seriously against losing the version number
Hi hackers,
It occurred to me that psql's \z command could benefit from the
addition of some newlines. With any more than one grantee per object,
the output of \z rapidly becomes extremely wide, and very hard to
read.
I'd like to split the output onto one line per grantee. So, instead of this:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 16, 2008 at 2:17 AM, Joshua D. Drake wrote:
On Tue, 15 Apr 2008 12:12:24 -0400
Alvaro Herrera wrote:
Tom Lane wrote:
I tend to just fix this stuff while committing, rather than lecture
the submitters about it, but it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 29, 2008 at 5:40 AM, Brendan Jurd wrote:
On 29/03/2008, Tom Lane wrote:
I intentionally didn't touch xml.c, nor anyplace that is not dealing
in text, even if it happens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 5:17 AM, Bruce Momjian
wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
This is one of the reasons I didn't want to add wiki maintenance to my
already full workload. Instead I am having to field complaints.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 6:03 AM, Merlin Moncure wrote:
One small point here. I've been mostly following this discussion on
this particular topic but have absolutely no idea what, if anything,
to do on the wiki in terms of submitting patch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 1:16 AM, Tom Lane wrote:
Brendan Jurd writes:
If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
have to revert those changes, and I'll have to seriously scale back
the cleanup patch I was about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 14, 2008 at 6:03 AM, Alvaro Herrera wrote:
Looks cool -- on a first read, I think you should add some more code
comments at the top of each function specifying whether the texts need
to be translated by the caller or done by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Apr 13, 2008 at 6:11 PM, Brendan Jurd wrote:
I've written a patch which implements the same \du behaviour as my
previous patch, but using the new printTable API
New versions of this patch, including changes made to the printTable API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and what did the reviewer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 4:12 AM, Tom Lane wrote:
Alvaro Herrera writes:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 6:39 AM, Tom Lane wrote:
Perhaps it would be useful to try to rate pending patches by difficulty?
Just a thought, but the file size of a context diff has a pretty good
correlation to the patch's intrusiveness /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 7:00 AM, Alvaro Herrera wrote:
Thanks, I changed a couple of patches to this method, and quickly hacked
up added a new template for reviews.
Re: horizontal whitespace in the patch template, I wonder if we can put
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Mar 21, 2008 at 7:47 AM, Tom Lane wrote:
I didn't do anything about removing A_Const's typename field, but I'm
thinking that would be a good cleanup patch.
Here's my attempt to remove the typename field from A_Const. There
were a few
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
Lastly, I would say that pushing submitters to enter their sent patches
into the Wiki worked -- we need to ensure that they keep doing it.
I'd also suggest, if you want to get serious about
On Tue, Mar 25, 2008 at 2:41 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
This makes me wonder whether print.c could offer something a bit more
helpful to callers wishing to DIY a table; we could have a
table-building struct with methods like addHeader
On Mon, Apr 14, 2008 at 8:45 AM, Dickson dos Santos Guedes
[EMAIL PROTECTED] wrote:
On Sat, Apr 12, 2008 at 7:43 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
I was going to try this patch out, but it would not apply. Seems that
where the patch should have , it has amp; instead. Has
On Sun, Mar 30, 2008 at 9:39 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
On 25/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
This makes me wonder whether print.c could offer something a bit more
helpful to callers wishing to DIY a table; we could
On Sat, Apr 12, 2008 at 3:53 AM, Dickson dos Santos Guedes
[EMAIL PROTECTED] wrote:
Well, working in the latest revision from CVS I added a feature for
psql to the command \d+, now it shows the object size as like as
\l+ show the database size.
I was going to try this patch out, but it
On Sat, Apr 12, 2008 at 3:13 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
The bug trackers I've dealt with haven't got much flexibility in this
respect either --- the sorts of global views you can get are entirely
determined by the tool. I'm fairly
On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark [EMAIL PROTECTED] wrote:
As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the
idea
of searching bugs. I don't really get why.
Er, because pretty
On Fri, Apr 11, 2008 at 1:06 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume you also read this Apache heading:
What if my patch gets ignored?
Because Apache has only a small number of volunteer developers,
and these developers are often very busy, it is possible
On Fri, Apr 11, 2008 at 1:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I just wanted to correct the apparent impression that patches don't
get ignored here. Patches get ignored. The difference between us
and Apache is we pretend it doesn't happen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 11, 2008 at 1:40 PM, Tom Lane wrote:
Brendan Jurd writes:
Not really. I'm claiming that, to the submitter, a response that
hasn't happened yet and a response that is never coming look pretty
much identical.
I understand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 12:33 AM, Bruce Momjian
wrote:
Heikki Linnakangas wrote:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 11:38 AM, Bruce Momjian
wrote:
I think there is concern that trivial patches wouldn't be submitted to a
patch tracker, especially by new submitters. Again, I am willing to
track the ones that aren't in the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 3:24 PM, Tom Lane wrote:
Brendan Jurd writes:
Personally I don't feel that using a patch tracker or wiki is any more
onerous than using an email list, and it's a whole lot more responsive
There are a couple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 8, 2008 at 6:33 PM, Heikki Linnakangas wrote:
For example:
9
4 9
2 4 0 9
The leaf nodes correspond the heap pages, so page #0 has 2 units of free
space, page #1 has 4, page #1 is full and page has 9.
Let's work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 5, 2008 at 10:00 AM, Gregory Stark wrote:
Regardless of whether we go ahead with this (and I'm not fond of it primarily
because I want \c to work),
Okay, but what on earth is \c and what would you expect it to do
when it works? I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 5, 2008 at 12:14 PM, Gregory Stark wrote:
Brendan Jurd writes:
Okay, but what on earth is \c and what would you expect it to do
when it works? I suppose you're connecting to a database, but
somehow I don't think you're talking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/03/2008, Tom Lane wrote:
Brendan Jurd writes:
1. describe malloc's the cells to zero, but print just does a local
calloc without any initialisation.
There isn't any functional difference there. I am not sure, but I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2008, Joshua D. Drake wrote:
Tom Dunstan wrote:
One answer is: what do you do if some required library isn't
available?
If we build by default, then when a library isn't found the configure
output tells you:
Looking for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moving to -hackers ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org
iD8DBQFH9RwN5YBsbHkuyV0RAr9ZAKD+XwNYYw3ugsTvowvKImOlKMZzPQCfTHkQ
u9jLkEIAWI/0MbNzzxBt0ok=
=So1n
-END PGP SIGNATURE-
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 4, 2008 at 6:35 AM, Bernd Helmle wrote:
Here's a quick and dirty patch which removes the responsible code from psql
(maybe not enough, but short testing shows it's working). Sorry for the
unified diff
I didn't realise it would
On 31/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
There isn't any functional difference there. I am not sure, but I think
the reason print.c has its own malloc wrappers instead of depending on
common.c's is that we use print.c in some bin/scripts/ programs that
do not want common.c too.
On 25/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
This makes me wonder whether print.c could offer something a bit more
helpful to callers wishing to DIY a table; we could have a
table-building struct with methods like addHeader and addCell.
Once
On 29/03/2008, Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Brendan Jurd [EMAIL PROTECTED] [080327 16:36]:
Looking at the CVS logs, there was definitely commit action in that
timeframe, but none of it is showing up on the git shortlog.
OK, so it should all be valid again.
Looks good
On 26/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
There are no textout/textin calls left, but I may have missed some
places that were doing it the hard way with direct palloc/memcpy
manipulations. It might be worth trolling all the VARDATA() references
to see if any more are easily
On 29/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
I intentionally didn't touch xml.c, nor anyplace that is not dealing
in text, even if it happens to be binary-compatible with text.
Hmm, okay. My original submission did include a few such changes; for
example, in xml_in and xml_out_internal I
On 28/03/2008, Aidan Van Dyk [EMAIL PROTECTED] wrote:
And I just forgot to re-enable my cron after I finished looking at it.
Ah, the old post-maintenance-disabled-cron gaff. One of my personal
favourites. =)
I'm not sure that the git repos has fully recovered. There seems to a
block of
On 27/03/2008, Gurjeet Singh [EMAIL PROTECTED] wrote:
Is the rsync daemon on anoncvs down? Is everyone else able to do rsync?
Possibly related; the Postgres git repository at
http://repo.or.cz/w/PostgreSQL.git is showing the last commit at 25
hours ago. It's usually a bit more spry than that.
On 26/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan's patch also included cstring_text_limit(const char *s, int len)
which was defined as copying Min(len, strlen(s)) bytes. I didn't find
this to be particularly useful. In the first place, all potential
callers are passing the exact
On 21/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
We can't just build the output table by hand like
describeOneTableDetails does? Admittedly it's kludgy, but it's not an
unprecedented kludge.
Oh, I had forgotten the existence of that entry point
On 21/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
As discussed on -hackers, this patch allows the construction of an
empty array if an explicit cast to an array type is given (as in,
ARRAY[]::int[]).
Applied with minor fixes; mostly, ensuring
On 21/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
The code is now set up so that it can pass an entire field value
through gettext(), but if gettext recognizes the strings foo and
bar that doesn't mean it will do anything useful with foo\nbar,
which is what this patch would require.
On 21/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
We can't just build the output table by hand like
describeOneTableDetails does? Admittedly it's kludgy, but it's not an
unprecedented kludge.
Oh, I had forgotten the existence of that entry point
On 20/03/2008, Tom Lane [EMAIL PROTECTED] wrote:
I started to look at applying this patch and immediately decided that
I didn't like these names --- it's exceeding un-obvious which direction
of conversion any one of the functions performs. Seems like every time
you wanted to call one,
On 08/03/2008, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know that's
true at least for me. If I want people to review my patch, I'm ready to
sing and dance if
to RFC again on Gregory's idea, and if that doesn't bear any
fruit I'd like to submit the patch as-is for review.
Regards,
BJ
On 01/12/2007, Brendan Jurd [EMAIL PROTECTED] wrote:
On Nov 30, 2007 9:09 PM, Gregory Stark [EMAIL PROTECTED] wrote:
I'm sorry to suggest anything at this point
301 - 400 of 511 matches
Mail list logo
