On Tue, Jan 20, 2009 at 2:44 AM, Rubén F. wrote:
> I have a doubt. I am designing a program for manage CV's. This program
> connect with a PostgresDB. This program will be used for 5,000 persons
> becaus it will be used in a University. Then, ¿how many actives connection
> could be postgres? ¿does
On Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd wrote:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names. This would make it easy to accept any flavour of marker,
> and the er
2009/9/4 Joshua D. Drake :
> On Thu, 2009-09-03 at 12:00 -0400, Robert Haas wrote:
>> And /me pokes Brendan Jurd. :-)
>>
>
> Hah! I almost listed him. /me adds a poke to Brendan Jurd.
>
/me stirs from sleep to announce "huh? whaddyawant?"
Seriously though,
2009/8/21 Brendan Jurd :
> 2009/8/21 Jeff Davis :
>> On Fri, 2009-08-21 at 12:23 +1000, Brendan Jurd wrote:
>>> The current behaviour seems to be predicated on the unique constraint
>>> being an integral part of the index itself. While this might be true
>>>
2009/9/9 Itagaki Takahiro :
> Alvaro Herrera wrote:
>> This INCLUDING STORAGE is supposed to copy reloptions?
>
> No. It copies only storage parameters of columns to control TOAST policy.
> It might be good to have some features to copy reloptions with convenient
> way, but it will be done in anot
2009/9/15 Jeff Davis :
> Attached is the latest version.
Hi Jeff,
I'm just getting started reviewing this version now. I noticed that
your patch seems to have been generated by git. Are you hosting this
work on a public repo somewhere that I can pull from? Also I think
the committers generally
2009/9/15 Jeff Davis :
> Attached is the latest version.
>
The new error message for a conflict is:
ERROR: index constraint violation detected
DETAIL: tuple conflicts with existing data
How about also including the name of the constraint (or index) that
was violated? I could imagine this erro
2009/9/15 Robert Haas :
> I believe the terminology we've been using, at least for the past year
> since I've been involved, is as follows:
>
> Open = open to new patches
> In Progress = working on reviewing and committing patches, no longer
> open to new patches
> Closed = all patches have been de
2009/9/16 Robert Haas :
> Instead of calling these generalized index constraints, I wonder if we
> oughtn't to be calling them something like "don't-overlap constraints"
> (that's a bad name, but something along those lines). They're not
> really general at all, except compared to uniqueness const
2009/9/16 Robert Haas :
> On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
>> I don't want to call them "don't overlap constraints", because it's not
>> limited to a non-overlapping constraint.
>
> Oh. What else can you do with it?
Anything that there is an operator for.
Cheers,
BJ
--
Sent
2009/9/16 Robert Haas :
> On Tue, Sep 15, 2009 at 1:14 PM, Brendan Jurd wrote:
>> 2009/9/16 Robert Haas :
>>> On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
>>>> I don't want to call them "don't overlap constraints", because it's not
&
Hi Dimitri,
The commitfest app has you listed as the reviewer for this patch. Any
progress on your review?
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2009/9/19 Tom Lane :
> Should we have it throw an error if the input corresponding to a G
> symbol doesn't match the expected group separator? I'm concerned that
> that would break applications that work okay today.
>
It would be a substantial change to the behaviour, and to do it
properly we'd h
2009/9/21 Jeevan Chalke :
> Oracle returns "19-SEP-09" irrespective of the format.
> Here in PG, we have getting the proper date irrespective of the format as
> Oracle. But in the case to to_number the returned value is wrong. For
> example following query returns '340' on PG where as it returns '3
2009/9/21 Brendan Jurd :
>
> # SELECT regexp_replace('34,50', E'[\\d.]', '', 'g')::numeric;
> 3450
>
Sorry, that regex ought to have read E'[^\\d.]'.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
2009/9/7 Itagaki Takahiro :
> Here is a patch to implement the following items in our ToDo list:
> * Add CREATE TABLE LIKE ... INCLUDING COMMENTS
> * Have CREATE TABLE LIKE copy column storage parameters
>
Hello Itagaki-san,
I am doing an initial review of your patch. I applied the version
lab
2009/9/19 Pavel Stehule :
> 2009/9/18 Selena Deckelmann :
>> Hi!
>>
>> John Naylor and I reviewed this patch. John created two test cases to
>> demonstrated issues described later in this email. I've attached
>> those for reference.
>>
>> On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule
>> wrote:
2009/9/28 Itagaki Takahiro :
> Thank you for reviewing.
> I merged your fix and add INCLUDING ALL option to the new patch.
> I changed InhRelation.options to be a bitmap of CreateStmtLikeOption.
> INCLUDING just adds bits, and EXCLUDING drops bits.
I had two hunks fail trying to apply your new pat
2009/9/28 Itagaki Takahiro :
> Brendan Jurd wrote:
>> patching file src/bin/psql/sql_help.c
>> Hunk #1 FAILED at 3.
>> Hunk #2 FAILED at 1279.
>> 2 out of 2 hunks FAILED -- saving rejects to file src/bin/psql/sql_help.c.rej
>
> Oops, sql_help.c is an automatic
2009/9/30 Pavel Stehule :
> So I dropped variadic functions from mixed/named notation and little
> bit modified documentation. Please, can some native English speaker
> look on documentation?
>
Hi Pavel,
I've had a look through the documentation and cleaned up a few things.
I changed the chapter
2009/10/6 Tom Lane :
> Applied with a fair amount of editorial polishing. Notably I changed
> the permissions requirements a bit:
>
Thanks and congratulations! I'm really looking forward to this feature.
I pulled the latest sources and gave it a whirl. Things worked as
expected in psql, but I
2009/10/6 Tom Lane :
> Brendan Jurd writes:
>> I pulled the latest sources and gave it a whirl. Things worked as
>> expected in psql, but I was a little surprised when I headed into the
>> documentation. The first place I visited was Chapter 20 - Database
>> Roles an
2009/10/7 Peter Eisentraut :
> On Sun, 2009-10-04 at 22:07 -0400, Tom Lane wrote:
>> In short: while I haven't looked at the patch, I think Peter may be
>> steering you in the wrong direction.
>>
>> In cases where you do have related functions, I suggest having
>> SQL-callable V1 functions that abs
2009/10/13 Tom Lane :
> I started looking at this, and the first thing I noticed was that it
> adds TABLES, FUNCTIONS, and SEQUENCES as unreserved keywords. Now
> I'm not a fan of bloating the parser that way, but I have to admit
> that "GRANT ON ALL TABLE IN SCHEMA" wouldn't read well. What I am
2009/11/2 Alvaro Herrera :
> Peter Eisentraut wrote:
>> As a compromise, we could keep the combined "Attributes" column but
>> replace the line breaks by commas. This would at least get rid of the
>> confusing and ugly line breaks in the common cases.
>
> That works for me.
Mmm, perhaps we were a
2009/11/13 Euler Taveira de Oliveira :
> Simon Riggs escreveu:
>> So, I
>> propose that we simply ignore patches from developers until they have
>> done sufficient review to be allowed to develop again.
>>
> Is it really impolite for a first-contributor, no?
>
I support Simon's proposal, but I thi
2009/11/14 Heikki Linnakangas :
> I think we (the commitfest manager?) should simply send polite message
> to any regulars who submits patches but hasn't volunteered for review.
> Along the lines of:
>
I certainly endorse Heikki's suggestion, but I wonder if we can do
more to make reviewing patche
2009/11/15 Jeff Davis :
> I know the error conventions are documented somewhere, but I completely
> forgot where. Can you please point me to the right place? I thought most
> error messages were supposed to be lower case, and detail messages were
> supposed to read like sentences.
http://www.postg
2009/11/10 Joshua Tolley :
> Ok, updated patch attached. As far as I know, this completes all outstanding
> issues:
>
Hi Joshua,
I'm taking a look at this patch for the commitfest. I see that Andrew
has already taken an interest in the technical aspects of the patch,
so I'll focus on submission/
2009/11/16 Andrew Dunstan :
> At Tom's suggestion I am looking at allowing use of parameter names in SQL
> functions instead of requiring use of $1 etc. That raises the question of
> how we would disambiguate a parameter name from a column name. Essentially,
> ISTM, we could use some special marker
2009/11/16 Tom Lane :
> The real problem with the entry that George picked up on was that it was
> misdescribed and mislabeled as easy because whoever put it in ignored
> the fact that there was not a consensus to do a half-baked fix ...
> this is a problem with a wiki TODO list :-(
Wouldn't it be
2009/11/17 David Fetter :
> In the PostgreSQL Weekly News, I track patches, and apparently at
> least one person reads that section. Would it be helpful to track
> reviews somehow during commitfests with the reviewers' names
> prominently attached?
>
Yes. See also my suggestion [1] that we do a
2009/11/17 Joshua Tolley :
> On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
>> I noticed that there was a fairly large amount of bogus/inconsistent
>> whitespace
...
>
> Thanks -- I tend to forget whitespace :)
>
>> In the documentation you refer to thi
On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> I haven't found any option to dump any user-defined function stored in a
> database, unless doing a pg_dump -D -s database, but so far one would get the
> definitions of the tables, the permissions, the triggers, and s
On Wed, Feb 27, 2008 at 2:29 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > You could just pull up a psql session and do a "select
> > pg_func_def(regproc);" and there you go, one fully formed CREATE
> > FUNCTION statement.
>
> \df+ function(type)
>
Sure, if your idea of a good time is lo
ke 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'
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 dan
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 on
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,
> > A
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 req
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
> > u
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
> > unprec
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
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 tha
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 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.
>
&
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 re
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_intern
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-buil
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
-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 diff
-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:
>
>
-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 Fri,
-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 woul
-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 "work
-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 co
-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
-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 track
-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
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 p
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 di
-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 l
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
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
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 mo
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, b
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
> &
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 hav
-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 revi
-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 revi
-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 / complexi
-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
>
-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
-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 f
-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 pri
-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 i
-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
-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 co
-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
-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 num
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:
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
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
the psql wrap patch I am working on now.
>
> Thanks. We've 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 no
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
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
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
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
> c
-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 e
-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
-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.
I'
-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
-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 P
-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
-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 sub
-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 enumerate
-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
301 - 400 of 513 matches
Mail list logo
