-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 ca
-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 v
-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 ei
-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 TL
-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, w
-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
g.org
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 th
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
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 upd
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 t
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
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+,
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
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
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, wra
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-progres
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 go
On Mon, Jan 26, 2009 at 8:32 AM, Alex Hunsaker wrote:
>
> -the various (only moved not added)
> strncpy(...)
> copy[len] = '\0';
>
> just use strlcpy?
>
Thanks for having a look Alex.
strlcpy would be easier, but I thought there might be portability
concerns re its non-entirely-standard status.
On Tue, Jan 27, 2009 at 3:05 PM, Tom Lane wrote:
> Brendan Jurd writes:
>> A quick grep through the backend code shows that strlcpy and strncpy
>> are both in use, with neither having a clear majority. I used strncpy
>> because it is more prevalent within src/backend/util
On Tue, Jan 27, 2009 at 3:25 PM, Brendan Jurd wrote:
> On Tue, Jan 27, 2009 at 3:05 PM, Tom Lane wrote:
>>
>> strncpy is generally deprecated; any remaining uses you find of it
>> are probably only there for lack of round tuits. Use strlcpy in new
>> code, unl
On Wed, Jan 28, 2009 at 1:35 AM, Robert Haas wrote:
>> I have started some very trivial work around this a while ago with the
>> intent to get something simple up and working before too much bike
>> shedding is done. I'll contact Robert off-list to discuss that. If
>> somebody else - who actively
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane wrote:
> The point I'm trying to make is that we should deliver IEEE-compliant
> results if we are on a platform that complies with the spec. Right down
> to the minus sign. If that surprises people who are unfamiliar with the
> spec, well, there are a l
On Wed, Feb 18, 2009 at 2:40 AM, Tom Lane wrote:
> After thinking about it for awhile, I don't like the notation anyway
> --- it's not immediately obvious that a cast to anyelement should mean
> something like that. What seems more sensible to me is to introduce
> a function to get the type of an
On Sun, Mar 15, 2009 at 4:39 AM, Tom Lane wrote:
> Whilst poking at bug #4702 I noticed that PG CVS HEAD rejects use of
> AD/BC notation, as well as CC (separate century) fields, in combination
> with ISO-style day numbers. I don't see the point of this. It's
> historically inaccurate, no doubt,
On Tue, Mar 31, 2009 at 2:26 PM, Tom Lane wrote:
> Does anyone want to argue for keeping it the same? Or perhaps
> argue that a zero-element array is a more sensible result than
> a one-element array with one empty string? (It doesn't seem
> like it to me, but maybe somebody thinks so.)
>
My fi
On Sat, Apr 11, 2009 at 2:16 AM, Pavel Stehule wrote:
>
> I was surprised so PostgreSQL doesn't support this basic output format.
>
Hi Pavel,
I had a look through your patch and would like to suggest improvements
to the new error messages you've introduced.
1. "invalid using of format "
Th
On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
wrote:
> The aspect of 8.3 behavior that concerns me most is that neither the
> author of a function, nor anyone using it, can control or predict
> which way a string literal with a backslash will be interpreted,
> unless the author explicitly specif
Hi guys,
I noticed the following item under "Observe the following
incompatibilities" in the 8.4 release notes (E.1.2.4.1.)
* Require to_timestamp() input to match meridian (AM/PM) and era
(BC/AD) format designations with respect to presence of periods
(Brendan Jurd)
For exam
s of to_timestamp().
To this item:
Cause to_date() and to_timestamp() to more consistently report
errors for invalid input (Brendan Jurd)
We could add a line like:
Some invalid inputs which were silently ignored or misread in 8.3
and earlier, will now cause an ERROR to be raised.
Cheers
On Mon, Apr 20, 2009 at 1:51 AM, Tom Lane wrote:
> Brendan Jurd writes:
>> There might be some value in changing the wording of that paragraph
>> about the "general tightening"
...
>
> OK, done. I wrote
>
> Previous versions would often ignore or sil
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule wrote:
> So, please, if you can, propose these error messages (with hints)-
> result will be much better.
>
Hi Pavel,
I was doing some work on rewording these error messages, and I noticed
that the following code segment occurs identically in four d
On Wed, Apr 22, 2009 at 10:13 AM, Pavel Stehule wrote:
> 2009/4/21 Brendan Jurd :
>> numstr = orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
>> if (Num.pre != 1)
>> ereport(ERROR,
>>
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule wrote:
> So, please, if you can, propose these error messages (with hints)-
> result will be much better.
>
Hi Pavel, hackers.
I've done some work updating Pavel's sci notation patch for to_char().
I've attached a patch against HEAD (_2.diff.bz
On Sun, May 17, 2009 at 1:40 PM, Tom Lane wrote:
> "Dickson S. Guedes" writes:
>> Is a simple "SELECT generate_series(now(), CAST('infinity'::date AS
>> timestamp), interval '1 hour');" working forever, an expected
>> behavior?
>
> Uh, what were you expecting it to do?
It appears that any genera
2009/6/11 Peter Eisentraut :
> Referenced by:
> "test2_y_fkey" IN test2 FOREIGN KEY (y) REFERENCES test1(a)
>
> Is there a magic reason why the IN is capitalized? (Maybe "from" would be
> better anyway?)
Isn't "on" the conventional preposition to use here? I would think of
this as a foreign key
2009/6/23 Tom Lane :
> Brendan Jurd writes:
>> I should be able to get the same results by snipping an extra
>> strspace_len() characters in the new code path in
>> from_char_parse_int_len(). This ought to be a one-line fix that
>> doesn't clobber the good parts o
2009/6/24 Jeremy Ford :
> I've just compiled and run the 8.4.RC2 code. For both of the following
> queries I get "0009-03-01"
>
> SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
> "0009-03-01"
> SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
>
> Was it
2009/7/2 Robert Haas :
> The main problem is that my fine software only contains test data at
> this point. If we have any volunteers who are available to migrate
> the information from the Wiki to my app (which will involve a fair
> amount of legwork),
As the original author of the CF wiki templ
2009/7/3 Robert Haas :
> Also, we're currently missing the reviewer names
> due to limitations of the import script; Brendan is fixing this.
Update: The reviewer names have now been populated.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
2009/7/3 Jaime Casanova :
> On Fri, Jul 3, 2009 at 12:34 AM, Brendan Jurd wrote:
>> 2009/7/3 Robert Haas :
>>> Also, we're currently missing the reviewer names
>>> due to limitations of the import script; Brendan is fixing this.
>>
>> Update
2009/7/4 Robert Haas :
> On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> What
>>> are the chances that the date or timestamp of the corresponding wiki
>>> modification could be put onto the patch and comment lines? (One
>>> would hope that could be done with a scri
2009/7/4 Tom Lane :
> No, what we're complaining about is the ordering of comments for a
> single patch.
Now moot, since I've successfully pulled the dates for all comments
with a message-id from the archives, and updated the database
accordingly.
Cheers,
BJ
--
Sent via pgsql-hackers mailing li
2009/7/3 Robert Haas :
> The application stamps comments with the
> community login of the person who left them, but the import stamped
> them with names instead. This is actually of some significance, since
> the app will allow you to edit your own comments but not those of
> other people. We co
Hi folks,
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to the
next commitfest and continue to use the wiki for July.
Robert and I have been upgrading the a
2009/7/8 Kevin Grittner :
> Oh, sure -- I post about it being down, and seconds after I hit send
> it comes up again. :-/
>
> Do we know that cause?
Well, no, since I've never observed it being "down" and I really have
no idea what you mean by that.
Maybe you could describe the symptoms you obs
2009/7/8 Alvaro Herrera :
>
> By the way, if the migration of the current commitfest was an automatic
> procedure, is there a chance that the old commitfests can be migrated as
> well?
>
It wasn't really automatic as such. I used a few scripts that I saved
in case we needed to use them again, but
2009/7/8 Peter Eisentraut :
> I have the following concern: Likely, this tool and the overall process will
> evolve over time. To pick an example that may or may not be actually useful,
> in the future we might want to change from a fixed list of patch sections to a
> free list of tags, say. Then
2009/7/7 Brendan Jurd :
> We're now about a week away from the start of the July 2009
> commitfest, and we need to make a decision about whether to start
> using http://commitfest.postgresql.org to manage it, or punt to the
> next commitfest and continue to use the wiki for Ju
2009/7/10 Tom Lane :
> While reorganizing my bookmarks for this I realized that there is a
> fairly significant bit of functionality that's entirely missing from
> the new app. With the wiki page, you could conveniently see what had
> been done lately by examining the page history. I don't see an
2009/7/10 Josh Berkus :
>
>> We don't AFAIK collect data about these events. However, we could
>> have certain actions trigger the creation of an automated comment
>> (e.g., "Status changed to Committed by petere") and let the
>> aforementioned comment view suffice for a "history".
>
> Can you put
2009/4/26 Brendan Jurd :
> I've done some work updating Pavel's sci notation patch for to_char().
That patch again, now with a couple of minor tweaks to make it apply
cleanly against the current HEAD.
Cheers,
BJ
_3.diff.bz2
Description: BZip2 compressed data
--
Sent via
2009/7/14 Robert Haas :
>
> +1 for redirecting the whole site. I don't think the extra CPU load
> of SSL is going to bother anyone for the amount of traffic we're
> likely to have on that site. Simplicity is good.
>
+1 for SSL on all pages from me also.
Cheers,
BJ
--
Sent via pgsql-hackers ma
2009/7/15 Andrew Dunstan :
> Dimitri Fontaine wrote:
>>
>> What I'm thinking about is to extend current "breadcumb" at the top of the
>> page to include chapter, section, subsection. So that for exemple the
>> following page:
>>
>> http://www.postgresql.org/docs/8.3/interactive/datatype-geometric.
2009/7/15 Jeff Davis :
> Updated patch attached.
>
> Changes:
> * Added syntax support:
> CREATE INDEX foo_idx ON foo ... (a CONSTRAINT =, b CONSTRAINT &&);
> * More aggressively clear the shared memory entries to avoid
> unnecessary checks
> * Code cleanup
>
> TODO:
> * When adding const
2009/7/17 Jeff Davis :
> Another idea that I thought about is that:
>
> ALTER TABLE foo ADD UNIQUE (a, b) USING foo_idx;
>
> could be a shorthand for:
>
> ALTER TABLE foo ADD INDEX CONSTRAINT (a =, b =) USING foo_idx;
>
> The benefit is that it could go over GiST indexes or hash indexes, not
>
2009/7/17 Josh Berkus :
> This seems like a serious issue for development. Reviewers, how many of you
> are able to build docs with each patch?
Being able to build docs did require some fidgeting with the docbook
packages (on Gentoo). The only trick was working out exactly which
packages I neede
2009/7/17 Kevin Grittner :
> Brendan Jurd wrote:
>
>> The only trick was working out exactly which
>> packages I needed to install.
>
> Which were?
>
Currently I have:
app-text/openjade 1.3.2-r1
app-text/docbook-sgml 1.0
app-text/docbook-sgml-dtd 4.2-r2
app-text/do
2009/7/14 Jaime Casanova :
> On Thu, Mar 26, 2009 at 2:39 AM, higepon wrote:
>> Here is a patch for pg_dump "Commenting on a composite-type column".
>> This patch is for Todo item named "Add dumping of comments on index
>> columns and composite type columns".
>
> this one looks good to me, the only
2009/7/24 David E. Wheeler :
> ROW(1, NULL) is neither NULL nor NOT NULL. I've no idea what state it is,
> but I guess that's the standard.
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
It doesn't really make sense to talk about the ROW itself being NU
2009/7/24 David E. Wheeler :
> It's useful to learn that `ROW(NULL, NULL)` is NULL, but I find the whole
> thing totally bizarre. Is it me?
>
*shrug* The IS [NOT] NULL tests mean something different when applied
to a ROW than they do when applied to a scalar value or an array.
"SELECT 1 IS NULL"
2009/7/24 Euler Taveira de Oliveira :
> Here is my review. The patch applied without problems. The docs and regression
> tests are included. Both of them worked as expected. Also, you included a fix
> in RN format, do it in another patch.
>
Well, I updated an error message for RN to keep it consis
2009/7/29 Euler Taveira de Oliveira :
> Looks better but I did some tests and caught some strange behaviors.
>
Pavel,
Any comment on these cases? When I looked at the patch I wasn't
really sure why it filled the string with '#' either, but I didn't
question it.
Cheers,
BJ
--
Sent via pgsql-ha
2009/7/29 Euler Taveira de Oliveira :
> This is not a problem with your patch but something that needs to be fixed in
> PostgreSQL to match Oracle behavior. The following example should emit an
> error. IMHO, filling the string with # is very strange. TODO?
>
> euler=# SELECT to_char(1234.56789, '9
2009/7/30 Pavel Stehule :
> 2009/7/29 Brendan Jurd :
>> I don't see any problem with extending this to allow up to 3 exponent
>> digits ... Pavel, any comment?
>
> I am not sure - this function should be used in reports witl fixed
> line's width. And I am think
2009/7/30 Euler Taveira de Oliveira :
>> So if you put the test inside the switch, it would need to appear in
>> every single branch of the switch except for the NUM_E one. I'm
>> confused about why you think this needs a comment. Perhaps I
>> misunderstood you?
>>
> Yes, I know you need to modif
2009/7/31 Euler Taveira de Oliveira :
> Brendan Jurd escreveu:
>> Limiting to two exponent digits also has the nice property that the
>> output always matches the length of the format pattern:
>>
>> 9.99
>> 1.23E+02
>>
> I don't think neglecting
2009/8/3 Pavel Stehule :
> 2009/8/2 Euler Taveira de Oliveira :
>> Tom Lane escreveu:
>>> The real bottom line for to_char issues is almost always that we should
>>> do what Oracle does. Has anyone checked this behavior on Oracle?
>>>
>> That was my point too. See [1].
>>
>> [1] http://archives.po
2009/8/3 Euler Taveira de Oliveira :
> Brendan Jurd escreveu:
>> Euler, could you post results for a number which fits within Oracle's
>> data type but has three exponent digits (like 1E+100)?
>>
> I don't access to an Oracle Server now but it works fine up to t
2009/8/3 Brendan Jurd :
> Okay, so Oracle just forces the output wider to accomodate the
> exponent (i.e., you can't rely on it being fixed-width).
>
> I can adjust the patch to imitate this behaviour; should be able to
> post a new revision within 24 hours.
>
Please fin
2009/8/3 Tom Lane :
> Euler Taveira de Oliveira writes:
>> As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to
>> 127).
>> In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999)
>> and
>> the double precision datatype can have up to 309 digits (ie 1e-307
2009/8/4 Tom Lane :
> Brendan Jurd writes:
>> Well, I tried this and as it turns out the patch casts the value to a
>> float8 in order to pass it on to snprintf for sci-notation formatting.
>
> Well, that's pretty dumb. Quite aside from the range problem, that
2009/8/4 Tom Lane :
> BTW, there's no rule saying you have to fix that strictly within
> to_char(). It might make more sense to have numeric.c export a
> function that is like numeric_out but produces e-style output.
> Your choice as the patch writer, but keep it in mind ...
>
Ah, thanks for the
2009/8/8 Bruce Momjian :
> Just to verify, this patch was about comments on composite columns, not
> about dumping comments on index columns (as the subject states), right?
> We do have a TODO for index column comments:
Correct.
If you scroll up a couple of messages [1] you'll see that I added th
2009/8/3 Tom Lane :
> Uh, no, we had better support more. The actual limit of the current
> numeric format is 1e+131072.
>
Given your comment above I'm thinking it reasonable to use an int32 to
store the exponent -- will that be safe?
That would allow for a maximum of 10 exponent digits. As an
2009/8/9 Tom Lane :
> Brendan Jurd writes:
>> That would allow for a maximum of 10 exponent digits. As an aside, I
>> note that int4out() hardcodes the maximum number of digits rather than
>> exposing a constant (c.f. MAXINT8LEN in int8.c). I'm considering
>> add
2009/8/9 Alvaro Herrera :
> Brendan Jurd escribió:
>
>> Here's version 6 of the patch, now with an all-new implementation
>> of (normalised) scientific notation in numeric.c, via the functions
>> numeric_out_sci() and get_str_from_var_sci(). So should no
2009/8/11 Tom Lane :
> Alvaro Herrera writes:
>> I wondered if it should just return char *. If we want to have this
>> functionality as its own fmgr-blessed function, shouldn't it return
>> text instead of cstring?
>
> If we expose it at fmgr level it should definitely not return cstring.
> Howe
2009/8/11 Tom Lane :
> If it's not meant to be in pg_proc, I wouldn't bother with using the V1
> call protocol for it. "extern char *numeric_out_sci(Numeric x)" would
> be sufficient, and less notation on both caller and callee sides.
>
Thanks Tom. I have removed the V1 stuff as you suggest, and
2009/8/11 Tom Lane :
> Working through this now, and I noticed that the example added to the
> manual seems to be wrong:
>
> to_char(0.000485, '9.99')
> ' 4.850e-04'
>
> With 9.99 as the pattern, I'd expect (and indeed I get) 4.85e-04
> not 4.850e-04. This is correct behavior, no
2009/8/11 Pavel Stehule :
> It's nice. I am playing with it, and now I found some potential issue.
> The parser is maybe too tolerant:
>
> postgres=# select to_char(3.14323,'9.9(a');
> to_char
> --
> 3.1e+00
> (1 row)
>
I guess we *could* add code to throw an error where the 9's
2009/8/11 Tom Lane :
> Brendan Jurd writes:
>> Here's version 7.
>
> Applied with a couple of corrections: the numeric case wasn't dealing
> with NaNs in the same way as the float cases,
Thanks for that.
I do think that the whole business of printing "#.#&q
2009/8/21 Heikki Linnakangas :
> Jeff Davis wrote:
>> I'm leaning toward not allowing it at CREATE TABLE time.
>
> Seems reasonable to me too.
>
+1
There are plenty of other things to do with tables that you can't mix
directly into a CREATE TABLE statement (grant permissions, create
triggers, cha
2009/8/21 Jeff Davis :
> If they include indexes and not constraints, I think we should follow
> the same policy as unique constraints, and create the index and the
> constraint.
>
> The behavior seems a little strange to me, but that's the current
> behavior for unique indexes.
This may be an opp
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
>> from a system catalog point of view (pg_index.in
Hello hackers,
I noticed that the table description given by \d in psql
does not indicate whether a trigger is enabled or disabled.
In my opinion, if a trigger is disabled, that fact is essential
information that a person looking at the output of \d would want to
know. I would like to add this
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled triggers are displayed as two separate footer
lists, for example:
T
On 11/7/06, Brendan Jurd <[EMAIL PROTECTED]> wrote:
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled t
While I was poking around in src/bin/psql/describe.c, I noticed that
when the query for inherited tables is opened, the code checks whether
the result is valid and if not, it goes straight to the error_return,
without clearing result sets that may have been open at the time. See
line 1174 in revi
On 11/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Is it crucial that result sets be cleared before going out of scope?
It sounds like it'd leak memory inside psql; but realistically that's
probably not an enormou
Hey hackers,
I was doing some work in backend/utils/adt/formatting.c, and found the
following:
case DCH_D:
INVALID_FOR_INTERVAL;
if (is_to_char)
{
sprintf(inout, "%d", tm->tm_w
On 11/11/06, Neil Conway <[EMAIL PROTECTED]> wrote:
The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look
closely, but you probably also leak result7 circa line 1209, if result6
is NULL.
New version of the patch attached (against CVS HEAD) that fixes these
two issues.
(Yeah
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Bruce Momjian escribió:
> Maybe now would be an appropriate time to discuss the open questions in
> the submitting email:
> > Brendan Jurd wrote:
> > > I'd also like to raise the topic of how conversion f
On 2/17/07, Martijn van Oosterhout wrote:
On Sat, Feb 17, 2007 at 02:41:32PM +1100, Brendan Jurd wrote:
> My gut reaction at first was to go with the former approach. It's
> programmatically more simple, and it's easier to explain in
> documentation/error messages. But the
As someone who's been lurking on the postgres lists for quite some
time, and submitted one (minor) patch, I think the notion of an
"entry-level" task list for we beginners is fantastic.
And, I'm sure this has been asked and answered a billion times
already, but why *don't* we have a real bug track
On 5/18/05, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
>
> The key requirement that has always come up is that the core developers
> wouldn't use anything web based, so the tracker would have to somehow tie
> into the mailing lists themselves ...
>
What's the basis of this objection to a web-ba
On 5/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> The Postgres project has been exceedingly successful while using email
> lists as the primary means of communication/organization. I for one
> am disinclined to tinker with such a fundamental aspect of the way that
> the community operates. If we
On 5/18/05, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Brendan Jurd ([EMAIL PROTECTED]) wrote:
> > In the interests of putting my money where my mouth is, I would be
> > willing to enlist in the housekeeping effort for this hypothetical new
> > system.
>
> If
On 5/18/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> O.k. then I misunderstood and apologize. I think the above is
> reasonable. I wouldn't think that the main developers would stop
> developing to create this system, nor would I want them to take time
> away from development to implement it.
>
Hi all,
I propose to add an internal function gettime() that transparently
returns the current system time, as a timestamptz with maximum
precision.
Calling gettime() would be a more elegant approach than calling
timeofday() and converting it to a timestamp, and avoids some of the
potential probl
401 - 500 of 513 matches
Mail list logo
