On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> We want patch submitters to spend their time on patches, not learning
> our style. The fact is that pgindent is a silver bullet in some ways.
Well there's a lot of support for the idea of pgindent being good
enough to establish a
On Nov 25, 2007 11:51 PM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> But that's not the point: more people will run into this problem and
> this looks like a showstopper for updating to 8.3.
>
> By the way, the function is named quote_literal(), not quote_text().
> From my point of view i
On Nov 26, 2007 5:23 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > So, I wonder why we don't just adapt the internal function to take
> > anyelement?
>
> The main argument against is the "slippery slop
On Nov 26, 2007 3:58 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 26, 2007 at 03:51:37AM +1100, Brendan Jurd wrote:
> > I noticed in the 8.3 release notes that ARRAY(SELECT ...) now returns
> > an empty array if there are no rows returned by the subque
Quoting Tom, from the previous thread linked by Martijn:
> It could be pretty ugly, because type assignment normally proceeds
> bottom-up :-(. What you might have to do is make the raw grammar
> representation of ARRAY[] work like A_Const does, ie, there's a
> slot to plug in a typecast. That's
On Nov 27, 2007 8:04 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > ... So
> > unfortunately I can't just add a TypeName member to ArrayExpr.
>
> That would be quite the wrong thing to do anyway, since ArrayE
So far I've only considered the '::' cast syntax suggested in the
original proposal, e.g.:
ARRAY[]::text[]
I wonder whether we are also interested in catching CAST(), e.g.:
CAST(ARRAY[] AS text[])
I'm personally okay with leaving it at support for '::', but
admittedly I am heavily biased toward
On Nov 28, 2007 2:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I wonder whether we are also interested in catching CAST(), e.g.:
>
> > CAST(ARRAY[] AS text[])
>
> I think you'll find that it's just about impossible to not handle both,
> because they look the same after the grammar gets done.
Tha
On Nov 28, 2007 4:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Now I'm thinking I leave the grammar rules alone (apart from making it
> > legal to specify an empty list of elements), and instead push the
On Nov 28, 2007 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I had a bit of a dig into this. A_Const->typename gets set directly
> > by the parse paths for "INTERVAL [(int)] string [interval range]". In
> > fact, as far as I can tell that's the _only_ place A_Const->typename
> > gets used at
Hi folks,
The patch is coming along nicely now. I do have a couple of questions
about the implementation in transformArrayExpr though.
1) How should we determine whether the array is multidimensional if we
know the type in advance?
Currently, transformArrayExpr uses the results of its sear
On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> i would also like to test another Beta, if we do something about this
> problem:
>
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php
Hi Andreas,
Tom's already committed the quote_literal(anyelement) f
On Nov 30, 2007 9:09 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm sorry to suggest anything at this point, but... would it be less invasive
> if instead of requiring the immediate cast you created a special case in the
> array code to allow a placeholder object for "empty array of unknown typ
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[]).
postgres=# select array[]::int[];
array
---
{}
postgres=# select array[];
ERROR: no target type for empty array
HINT: Empty arrays must be
On Dec 10, 2007 10:39 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I like the realease notes intro. You may have already picked up on
these, but a couple typos:
> A names appearing next to an item represents the major developer for
> that item. Of course all changes involve comm
On Dec 23, 2007 12:20 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Gurjeet Singh wrote:
> > On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > This way, if the attacker has control of even one interface (and
> > optionally the local socket) that the clients are expected to
On Dec 23, 2007 1:25 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I have written documentation for this item:
>
> http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING
>
> Comments?
I thought the content made sense, but the location didn't. I wouldn't
expect to find instructi
On Jan 10, 2008 2:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> You'd have to define exactly what that means, which seems a little
> tricky for incommensurate intervals. For instance what is the
> result of '1 month' / '1 day' ?
>
Postgres has already made such definitions, to allow direct
interva
On Jan 10, 2008 3:33 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> 1 month is deemed equal to 30 days, 1 day is deemed equal to 24 hours
> (although for some reason we ignore the issue of years vs. days).
>
Sorry, a correction. The issue of years vs. days isn't ignored. A
ye
On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The spec's approach to datetime operations in general is almost totally
> brain-dead, and so you won't find a lot of support around here for hewing
> to the straight-and-narrow-spec-compliance approach. If they have not
> even heard of
On Jan 17, 2008 8:22 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > >
> > >> A further example shows that to_date seems to have little error checking
> > >> altogether:
> > TODO list item?
>
> We have
On Jan 18, 2008 3:19 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
> > statement?
>
> no, isn't. SELECT CASE can be only in expression .. inside SQL
> statement, but PL/SQL CASE is PL statement. These are two different
> w
On Jan 26, 2008 8:14 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> This two-faced personality is just why we're facing this problem. It looks to
> users like DML but it under the hood it behaves just like DDL.
>
Agreed that it looks like DML. Speaking as a user, I came away from
the documentatio
This all sounds very promising.
On Feb 6, 2008 7:56 PM, Dave Page <[EMAIL PROTECTED]> wrote:
> Each fest will continue until all patches in the queue have
> either been committed to the CVS repository, returned to the author
> for additional work, or rejected outright, and until that has
> happene
On Feb 8, 2008 10:29 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Freitag, 8. Februar 2008 schrieb Markus Bertheau:
> > Maybe the existing SVN, git and other mirrors could just become more
> > official and supported in the sense that users can rely on them to be
> > updated often enough?
>
On Feb 10, 2008 3:50 AM, Patrick Welche <[EMAIL PROTECTED]> wrote:
> NOTICE: (1,two,"Sat 09 Feb 16:47:44.514503 2008")
> INSERT 0 0
>
I think what you're seeing is the syntax for row literals.
You can get an idea of how it looks without having to write trigger
functions, e.g.:
> select row(1, '
On Feb 10, 2008 8:58 AM, Jan Wieck <[EMAIL PROTECTED]> wrote:
> I wonder if the efforts to provide mirrors for many different systems can
> hurt later down the road. It is pretty obvious that amost every current
> system has options to convert from or to mirror a CVS repository. But what if
> we
Though to be safe you should be quoting MT and ST with quote_ident()
before putting them into a dynamic statement.
Cheers
BJ
On Feb 12, 2008 4:38 PM, Brett McBride <[EMAIL PROTECTED]> wrote:
> you could do this with 'execute' like so:
>
> execute 'select count(*) into count1 from ' || MT || ','
On Feb 13, 2008 10:45 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> For the patches lists I need to take sometimes entire threads, sometimes
> groups of comments, and store them in a format so people can review them
> as a digest. And I want to allow comments on these items, and ideally
> allow m
Hello hackers,
psql's \du command currently does not list the INHERIT role attribute.
It does show the other privilege attributes (superuser, create role,
create db), and INHERIT seems like the kind of thing a user
executing\du would want to know.
I'd like to add it to \du. The downside is that
On Fri, Feb 15, 2008 at 3:42 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now that psql prints multiline field values nicely, maybe it'd work
> to fold all the boolean attributes into one column. I'm imagining
> something like
>
> Role name | Privileges | Member of
> --+-+--
On Fri, Feb 15, 2008 at 10:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > What about connection limit? I suppose we could combine it into the
> > privileges column, and refrain from displaying anything for "
On Fri, Feb 15, 2008 at 12:19 PM, Decibel! <[EMAIL PROTECTED]> wrote:
> On Feb 14, 2008, at 7:27 AM, Alvaro Herrera wrote:
> > Attributes: S -- superuser
> > R -- create role
> > D -- create database
> > I -- inherit
>
>
> Can we add something similar to the bot
I've done up a patch per Tom's idea of combining the binary role
attributes into a single column.
Each attribute which differs from the default is listed on a separate
line, like so:
List of roles
Role name | Attributes | Member of
-++-
2009/11/29 Bruce Momjian :
> Wow, we mention 28k modems --- we are legacy software: ;-)
>
> This initial checkout is a little slower than simply downloading
> a tar.gz file; expect it to take 40 minutes
> or so if you have a 28.8K modem.
Yes, and what about all the people using carrie
2009/12/3 Ron Mayer :
> Tom Lane wrote:
>> Hmm. So the argument for it is "let's make a machine-readable format
>> more human-readable"? I'm not getting the point. People should look
>> at the regular text output.
>
> IMHO YAML beats the regular text format for human-readability -
> at least for
2009/12/20 Peter Eisentraut :
> Could we create an option to create index names automatically, so you'd
> only have to write
>
> CREATE INDEX ON foo (a);
Yes, please.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
2010/1/23 Mark Mielke :
> Calling it
> "PostgreSQL", makes it very clear to the uninformed masses where the product
> fits in a product map. Tell an executive of a company "Postgres", and they
> would ask "what is it?" Tell them "PostgreSQL", and they'll say "is that
> like Oracle?" The second is h
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 t
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
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
&g
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
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
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 alre
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 s
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
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:
> http://wiki.postgresql.org/index.php?tit
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 pe
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&#x
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&#
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 wr
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, an
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
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.
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> Im just following this:
> http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
>
Hi Alex. Thanks for taking the time to review my patch.
> Feature test: Everything seems to work as advertised. However be
On Mon, Sep 8, 2008 at 6:24 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
>> Code review: one minor nit
>> *** a/src/backend/utils/adt/formatting.c
>> --- b/src/backend/utils/adt/formatting.c
On Mon, Sep 8, 2008 at 6:59 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Here is a revised version of the pgbench duration patch.
> I merged some comments from Brendan and gnari.
>
The changes look good. I tried out the new v3 patch and didn't
encounter any problems.
One last minor quibble
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
> I actually had a look at this patch also, though not as thoroughly as
> Alex. There was one part that I had some thoughts about in
> from_char_parse_int_len:
>
Hi Martijn. Thanks for your comments.
> The use of
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
> <[EMAIL PROTECTED]> wrote:
>> The use of palloc/pfree in this routine seems excessive. Does len have
>> upper bound? If so a simple arra
On Fri, Sep 12, 2008 at 3:34 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Applied with minimal modifications. I changed a couple of error
> messages that didn't seem to meet the style guidelines,
Great, thanks Tom. And thanks again to Alex and Martijn for helping
me refine the patch.
> and I moved
Hi Magnus,
Josh has assigned your patch to me for an initial review.
First up I'd like to say that this is a really nice upgrade.
Shielding a running server from reloading a bogus conf file makes a
whole lot of sense.
On Sun, Aug 17, 2008 at 1:47 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
On Mon, Sep 15, 2008 at 10:53 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
> Thanks for the reviews, guys. I've adjusted the patch per your comments
> (I think), and applied it.
>
Cool. I had a look at the commitdiff and I think you missed one of
the error messages (it's still all on one line
On Mon, Sep 15, 2008 at 11:46 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> Hm, that doesn't seem like a great improvement --- in particular, it
>> violates the style guideline that detail messages should be complete
>> sentences.
>>
>> I think the error text is all right a
Hey folks,
Tom pointed out in the parent thread [1] that the error message for
bogus AM/PM markers in to_timestamp is pretty lame:
ERROR: invalid AM/PM string
I agree, and once I started thinking about this, I came up with other
gripes concerning the treatment of 12-hour time in to_timestam
On Sat, Sep 27, 2008 at 4:08 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> However that still leaves the original complaint around (at least IMHO):
>
>> select to_timestamp('AN', 'AM');
>> ERROR: invalid AM/PM string
>
>> select to_timestamp('11:47 PM 27
On Mon, Nov 3, 2008 at 2:31 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The problem I'm having with this is that the current scheme for naming
> commitfest pages assumes you know the date for each one. It seems way
> premature to bet on when the first 8.5 fest will start.
>
> Wikimedia does seem to
Hi Jeff,
I've been assigned to do an initial review of your "new correlation
metric" patch.
If I'm grokking the thread, it looks like Tom suggested a substantial
change in the approach (targetting per-index correlation rather than
per-column) [1], and although you agreed with the spirit of his
su
On Tue, Nov 4, 2008 at 6:12 AM, Enrico Pirozzi <[EMAIL PROTECTED]> wrote:
> Hi all, I'm new in list
>
Hi Enrico,
Just a heads-up, the Postgres hackers have just started on the final
"commitfest" (patch review phase) for the 8.4 development cycle, so at
the moment everyone is busy reviewing patche
On Tue, Nov 4, 2008 at 4:21 AM, Jeff Davis <[EMAIL PROTECTED]> wrote:
> We don't want to hold anything up, so feel free to move on to another
> patch. If you still have time to review when we have a better patch,
> we'd appreciate your feedback even if it's too late for 8.4.
>
No worries, thanks J
On Thu, Sep 18, 2008 at 6:03 AM, Ron Mayer
<[EMAIL PROTECTED]> wrote:
> The attached patch
> (1) adds a new GUC called "IntervalStyle" that decouples interval
> output from the "DateStyle" GUC, and
> (2) adds a new interval style that will match the SQL standards
> for int
On Wed, Nov 5, 2008 at 7:34 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> Brendan Jurd wrote:
>> When I ran the regression tests, I got one failure in the new interval
>
> Fixed, and I did a bit more testing both with and without
> HAVE_INT64_TIMESTAMP.
Confirmed, all regress
On Thu, Oct 2, 2008 at 9:31 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> Ron Mayer wrote:
> This patch (that works on top of the IntervalStyle patch I
> posted earlier today) adds support for ISO8601 standard[0]
> "Time Interval" "Durations" of the "format with designators"
> (section 4.4.4.2.1). T
On Thu, Nov 6, 2008 at 3:36 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> Wow thanks! That's very helpful (though it might have been more
> fair to your time if you just kicked it back to me saying "rewrite
> the docs" so they make sense)!
>
Maybe ... but I figured it would take more time to fully e
On Fri, Nov 7, 2008 at 3:35 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> I think I updated the web site and git now, and
> 'P-00-01' is now accepted. It might be useful if
> someone double checked my reading of the spec, tho.
>
Hi Ron,
I've tested out your latest revision and read the spec mo
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
<[EMAIL PROTECTED]> wrote:
> I updated my web site[1] with the latest version of this patch.
I'm just testing this latest version out now.
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=
On Sat, Nov 8, 2008 at 2:19 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
>
> Hmmm... Certainly what I had in datatype.sgml was wrong, but I'm
> now thinking 5.5.4.2.1 and 5.5.4.2.2 would be the most clear?
>
Sorry, I don't understand what you mean by "5.5.4.2.1". In the spec
you linked to, clause 5 "
On Tue, Nov 11, 2008 at 5:51 AM, R Mayer
<[EMAIL PROTECTED]> wrote:
> Applied and pushed to the website http://0ape.com/postgres_interval_patches/
>
This latest version works as expected and I don't detect any other
issues with the code or documentation ... seems I've run out of things
to gripe ab
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> # Patch 3: "cleanup.patch"
> Fix rounding inconsistencies and refactor interval input/output code
>
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes attached.
If I'm rea
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
<[EMAIL PROTECTED]> wrote:
> Brendan Jurd wrote:
>> * AdjustFractionalSeconds => AdjustFractSeconds
>> * AdjustFractionalDays => AdjustFractDays
>
> Otherwise many lines were over 80 chars long.
> And it happened oft
On Wed, Nov 12, 2008 at 6:13 AM, Ron Mayer
<[EMAIL PROTECTED]> wrote:
> Brendan Jurd wrote:
>> I don't have any further gripes regarding this patch, apart from the
>> code style stuff I sent through in my previous post. Did you have any
>> response to those
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah. An example of a closely related expression that it *would* be
> able to prove self-contradictory is
>WHERE x = ALL (ARRAY[1, 2, ...])
> or perhaps slightly more realistically
>WHERE x = ANY (ARRAY[1, 2, 3]
On Thu, Nov 13, 2008 at 5:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> I guess my question is, what's the real benefit of going to all this
>> trouble trying to prove that clauses are false?
>
> Not
On Tue, Nov 25, 2008 at 7:31 PM, Dave Page <[EMAIL PROTECTED]> wrote:
> I'm in favour of including it by default (at initdb), so it's there
> for new users to play with on any fresh install ...
Could we perhaps punt on the issue of whether to install the
"sampledb" by default. It could be control
On Mon, Dec 1, 2008 at 11:08 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
> HH24:MI:SS'); -- doesn't work
...
> I think the end of string should be treated like a field separator, colon in
> this example, and we should accept b
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane wrote:
> ISTM one could make a pretty good argument that this last case should
> succeed, producing an empty-array argument. If you buy that, then it
> is sensible to forbid defaults for variadics,
Yep, +1 for this approach. I would intuitively expect
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane wrote:
> Actually, I just realized that there's another fly in the ointment:
> the current variadic code allows "variadic anyarray", which is
> equivalent to an appropriate number of anyelement arguments. If we
> allow defaulting then there's a big probl
On Thu, Jan 8, 2009 at 2:10 PM, Bruce Momjian wrote:
> Brendan, did you ever complete this patch?
>
I didn't, no. I still intend on doing work in this area, but
obviously it will have to be in the 8.5 cycle.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Thu, Jan 8, 2009 at 2:20 PM, Bruce Momjian wrote:
> OK, what is the TODO? It is more than AM/PM, right?
>
I see it happening in two stages.
Stage 1 is updating the AM/PM parse code to use the seq_search
technique, which may involve some minor refactoring around seq_search
itself. This will
On Thu, Jan 15, 2009 at 9:14 PM, Jasen Betts wrote:
> On 2009-01-14, Gerhard Heift wrote:
>> Hello,
>>
>> is it possible to call a trigger for a row in a table without updating the
>> row? I want to do it in plpgsql.
>
>> Something like UPDATE table WHERE id = 10;
>
> when faced with that problem
On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane wrote:
> The problem is that you, me, and the people we know are the only ones
> who actually use \df to see system functions. 99.99% of users don't care,
> or don't even know, about the system functions - but they do care about
> being able to
Hey all,
I recently had pg_dump produce a non-restorable dump for one of my
databases. I can't share the dump itself, but I can describe what
went wrong.
This database had a user-defined composite type in it. I wanted to be
able to GROUP BY this type, so I added a family of comparison
functions
On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>> * It seems there's no pg_depend entry for
>> types/functions/operators/opclasses that the view depends on, unless
>> they are part of the SELECT list.
>
> What PG version
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> Looking at it some more, I notice that the SortGroupClause dependencies
> are on the individual operators, which probably isn't good enough: the
> operator *classes* have to exist or the parser will complain when trying
> to make sense of the vie
On Sun, Jan 18, 2009 at 1:41 AM, Brendan Jurd wrote:
> ... but I'm confused as to why 8.4
> doesn't freak out when told to create a view it doesn't actually know
> how to execute. Have the rules for evaluating views changed?
>
Update. Turns out that 8.4 DOES know h
On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>> Update. Turns out that 8.4 DOES know how to execute the view. If you
>> try to group on a user-defined composite type, 8.4 just goes ahead and
>> groups it, rather than giving the old
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> However --- it's also the case that
> pg_dump should dump all operators *and* operator classes before it gets
> to views. So either you were doing something funny with the dump/reload
> or else there's a circular dependency in your DB that pg_du
On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane wrote:
> Interesting --- it works as expected in 8.2. The problem seems to have
> been created by the introduction of arrays over composites in 8.3.
Congratulations on identifying the source!
Does this also explain the extra-weird output from HEAD, with
On Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd wrote:
> Currently, Postgres accepts four separate flavours for specifying
> meridiem markers, given by uppercase/lowercase and with/without
> periods:
>
> * am/pm
> * AM/PM
> * a.m./p.m.
> * A.M./P.M.
>
> I wou
On Mon, Jan 19, 2009 at 7:47 AM, Tom Lane wrote:
> I've applied a patch for this to HEAD and 8.3.
>
Cool, thanks Tom.
Just noting that I've tested your fix on both branches, and in both
cases pg_dump's output came out nice, clean and consistent.
Cheers,
BJ
--
Sent via pgsql-hackers mailing li
201 - 300 of 513 matches
Mail list logo
