On Sat, 6 Feb 2016 at 12:50 Tom Lane wrote:
> Robert Haas writes:
> > I agree with what Merlin said about this:
> >
> http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yc10ahu1nfia1tbhsg+35ds-oeueuapo7...@mail.gmail.com
>
> Yeah, I agree that a GUC for this is quite unappetizing.
>
How would
On Tue, 30 May 2017 at 05:30 Christoph Berg wrote:
> Oh interesting, I didn't know about pager_min_lines. That sounds
> useful as well. +1 on the analogous pager_min_cols option.
>
On closer inspection, I note that psql already has a 'columns' \pset
option, which does control the width for trigg
Hello hackers,
I am often frustrated by the default behaviour of the psql pager, which
will activate a pager if the output is deemed to be "too wide" for the
terminal, regardless of the number of lines output, and of the
pager_min_lines setting.
This behaviour is sometimes desirable, but in my us
On Fri, 30 Oct 2015 at 00:51 Tom Lane wrote:
> The really key argument that hasn't been addressed here is why does such
> a behavior belong in psql, rather than elsewhere? Surely legibility
> problems aren't unique to psql users. Moreover, there are exactly
> parallel facilities for other datat
On 19 February 2012 06:52, Tom Lane wrote:
> Yeah ... if you *don't* know the difference between a DFA and an NFA,
> you're likely to find yourself in over your head. Having said that,
> this is eminently learnable stuff and pretty self-contained, so somebody
> who had the time and interest could
On 19 February 2012 15:49, Tom Lane wrote:
> That sounds great.
>
> BTW, if you don't have it already, I'd highly recommend getting a copy
> of Friedl's "Mastering Regular Expressions". It's aimed at users not
> implementers, but there is a wealth of valuable context information in
> there, as we
On 20 February 2012 10:42, Tom Lane wrote:
> I have also got
> a bunch of text about the colormap management code, which I think
> is interesting right now because that is what we are going to have
> to fix if we want decent performance for Unicode \w and related
> classes (cf the other current -h
Hello folks,
I am in the process of accelerating down the rabbit hole of regex
internals. Something that came up during my reading, is that a POSIX
compliant regex engine ought to always prefer the longest possible
match, when multiple matches are possible beginning from the same
location in the
On 4 March 2012 17:53, Tom Lane wrote:
> Brendan Jurd writes:
>> I'll admit that this is a pretty obscure point, but we do appear to be
>> in direct violation of POSIX here.
>
> How so? POSIX doesn't contain any non-greedy constructs. If you use
> only the
On 5 March 2012 04:34, Tom Lane wrote:
> Brendan Jurd writes:
>> On 4 March 2012 17:53, Tom Lane wrote:
>>> Brendan Jurd writes:
>> While it's true that POSIX doesn't contemplate non-greed, after
>> reading the spec I would have expected an expres
On 5 March 2012 17:23, Robert Haas wrote:
> This is different from what Perl does, but I think Perl's behavior
> here is batty: given a+|a+b+ and the string aaabbb, it picks the first
> branch and matches only aaa.
Yeah, this is sometimes referred to as "ordered alternation",
basically that the b
On 31 May 2013 02:52, Dean Rasheed wrote:
> Testing 9.3beta, it seems that array_remove() may return an empty 1-d
> array whose upper bound is lower than its lower bound. I know that we
> discussed allowing this kind of array, but I don't think that
> discussion reached any conclusion, other than
On 12 June 2013 04:43, Josh Berkus wrote:
> What's the status on this patch and current approach to ZDA?
Alright, it might be a good idea to have a quick recap.
Last time, on Arrays Of Our Lives ...
So I proposed and posted a patch aimed at deprecating zero-D arrays,
and replacing them with 1-D
On 12 June 2013 18:22, Dean Rasheed wrote:
> +1 for having a function to return the total number of elements in an
> array, because that's something that's currently missing from SQL.
>
> However, I think that CARDINALITY() should be that function.
>
> I'm not convinced that having CARDINALITY() r
On 13 June 2013 04:26, Merlin Moncure wrote:
> On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 06/12/2013 11:01 AM, Tom Lane wrote:
I'm going to be disappointed if all we can get out of this is
a cardinality() function, and nothing is done about the empty
On 14 June 2013 03:53, David E. Wheeler wrote:
> Similar things should have dissimilar names. I propose:
>
>
>
> Old |New
> --+--
> array_dims | array_desc
array_bounds?
> array_ndims | array_depth
> array_length | array_size
> array_lower | array_s
On 15 June 2013 14:43, Craig Ringer wrote:
> The #1 question I see on Stack Overflow has to be confusion about
> pg_hba.conf, mostly from people who have no idea it exists, don't understand
> how to configure it, etc.
The totally non-obvious name of the file probably has something to do
with that
On 15 June 2013 16:18, Craig Ringer wrote:
> On 06/15/2013 02:08 PM, Brendan Jurd wrote:
>> On 15 June 2013 14:43, Craig Ringer wrote:
>>> The #1 question I see on Stack Overflow has to be confusion about
>>> pg_hba.conf, mostly from people who have no idea it exists,
On 25 June 2013 04:13, Joshua D. Drake wrote:
> On 06/24/2013 10:59 AM, Andres Freund wrote:
>> On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
>>> This project is enormously stingy with giving credit to people. It's
>>> not like it costs us money, you know.
>> I am all for introducing a "Contri
On 26 June 2013 03:17, Josh Berkus wrote:
> How should reviewers get credited in the release notes?
>
> a) not at all
> b) in a single block titled "Reviewers for this version" at the bottom.
> c) on the patch they reviewed, for each patch
A weak preference for (c), with (b) running a close secon
On 1 July 2013 17:47, Pavel Stehule wrote:
> 2013/6/29 Pavel Stehule :
>> long time I am thinking about simple function for creating date or
>> timestamp values based on numeric types without necessity to create
>> format string.
>>
>> What do you think about this idea?
> I found so same idea was
On 3 July 2013 21:41, Pavel Stehule wrote:
> I am thinking so for these functions exists some consensus - minimally
> for function "date"(year, month, int) - I dream about this function
> ten years :)
>
> I am not sure about "datetime":
> a) we use "timestamp" name for same thing in pg
> b) we can
On 20 December 2012 11:51, Tom Lane wrote:
>
> While reconsidering the various not-too-satisfactory fixes we thought of
> back then, I had a sudden thought. Instead of having a COMMUTATOR or
> NEGATOR forward reference create a "shell" operator and link to it,
> why not simply *ignore* such refer
Hi folks,
I have a project which uses Postgres asynchronous notifications pretty
heavily. It has a particularly Fun failure mode which causes the
notification queue to fill up. To better debug this problem I'd like
to be able to monitor the size of the notification queue over time.
It doesn't l
On 7 February 2013 08:07, Josh Berkus wrote:
> The existing Gerrit community would be keen to have the PostgreSQL
> project as a major user, though, and would theoretically help with
> modification needs. Current major users are OpenStack, Mediawiki,
> LibreOffice and QT.
Do we actually have any
On 16 March 2013 09:07, Tom Lane wrote:
> "David E. Wheeler" writes:
>> This surprised me:
>
>> david=# select array_length('{}'::text[], 1);
>> array_length
>> --
>>[null]
>
>> I had expecte dit to retur 0. I might expect NULL for a NULL param, but not
>> on
On 17 March 2013 05:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 16 March 2013 09:07, Tom Lane wrote:
>>> The thing is that that syntax creates an array of zero dimensions,
>>> not one that has 1 dimension and zero elements.
>
>> I'm going to ask th
On 17 March 2013 06:27, Tom Lane wrote:
> What I'm concerned about here is whether these expressions shouldn't
> be yielding different data values:
>
>
> Right now, if we did make them produce what they appear to mean, the
> array I/O functions would have a problem with representing the results:
On 17 March 2013 05:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 16 March 2013 09:07, Tom Lane wrote:
>>> The thing is that that syntax creates an array of zero dimensions,
>>> not one that has 1 dimension and zero elements.
>
>> I'm going to ask th
Hi hackers,
While I was working on my empty array patch I was frequently irritated
by the absence of an array_length(anyarray). The same goes for
array_upper and array_lower. Most of the time when I work with
arrays, they are 1-D, and it's inelegant to having to specify which
dimension I mean wh
On 21 March 2013 17:08, Pavel Stehule wrote:
> 2013/3/21 Tom Lane :
>> I'm not entirely convinced that this is a good idea, but if we're going
>> to allow it I would argue that "array_length(a)" should be defined as
>> "array_length(a, 1)". The other possibilities are too complicated to
>> explai
On 21 March 2013 17:32, Pavel Stehule wrote:
> If I though about it more, I like to more limit one parametric
> array_length function just for only 1D array. So it is your A use
> case. But I understand so this variant is not orthogonal. Hard to say,
> what is better.
>
Yes, for me (a) is running
On 22 March 2013 09:12, Merlin Moncure wrote:
> On Thu, Mar 21, 2013 at 2:00 AM, Pavel Stehule
> wrote:
>> lot of postgresql functions calculate with all items in array without
>> respect to dimensions - like unnest.
>>
>> so concept "use outermost dim" is not in pg now, and should not be
>> int
On 25 March 2013 13:02, Josh Berkus wrote:
> On 03/20/2013 04:45 PM, Brendan Jurd wrote:
>> Incompatibility:
>> This patch introduces an incompatible change in the behaviour of the
>> aforementioned array functions -- instead of returning NULL for empty
>> arrays th
On 26 March 2013 00:30, Tom Lane wrote:
> Brendan Jurd writes:
>> On 25 March 2013 13:02, Josh Berkus wrote:
>>> Brendan, how hard would it be to create a GUC for backwards-compatible
>>> behavior?
>
>> Good idea.
>
> No, it *isn't* a good idea. G
On 21 March 2013 10:45, Brendan Jurd wrote:
> src/test/isolation/expected/timeouts.out| 16 +-
> src/test/isolation/specs/timeouts.spec | 8 +-
Oops, looks like some unrelated changes made their way into the
original patch. Apologies. Here's a -v2 patch, san
On 26 March 2013 05:26, Greg Stark wrote:
> I'm not as sanguine as Tom is about how likely these corner cases will
> be met actually. As far as I can tell checking IS NULL on
> array_length() was the supported way to check for 0-length arrays
> previously
Correct. There was no other way to check
On 26 March 2013 05:04, Darren Duncan wrote:
> On 2013.03.25 1:17 AM, Albe Laurenz wrote:
>> The desired effect can be had today with a unique index:
>>
>> CREATE TABLE singleton (id integer);
>> CREATE UNIQUE INDEX singleton_idx ON singleton((1));
>
> Okay, that is helpful, and less of a kludge t
On 26 March 2013 22:57, Robert Haas wrote:
> They hate it twice as much when the change is essentially cosmetic.
> There's no functional problems with arrays as they exist today that
> this change would solve.
>
We can't sensibly test for whether an array is empty. I'd call that a
functional pro
On 27 March 2013 06:47, Robert Haas wrote:
> On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd wrote:
>> We can't sensibly test for whether an array is empty. I'd call that a
>> functional problem.
>
> Sure you can. Equality comparisons work just fine.
>
> rha
On 28 March 2013 00:21, Dean Rasheed wrote:
> The patch is also allowing '{{},{},{}}' which is described up-thread
> as a 2-D empty array. That's pretty misleading, since it has length 3
> (in the first dimension). '{{},{}}' and '{{}}' are both "more empty",
> but neither is completely empty.
> I
On 28 March 2013 09:39, Dean Rasheed wrote:
> On 27 March 2013 17:14, Brendan Jurd wrote:
>> Well the fix is primarily about 1-D empty arrays, and in that respect
>> it is much less confusing than what we have now.
>
> Maybe. But even in 1-D, it's still jumping from h
On 28 March 2013 20:34, Dean Rasheed wrote:
> Is the patch also going to allow empty arrays in higher dimensions
> where not just the last dimension is empty?
It doesn't allow that at present.
> It seems as though, if
> it's allowing 1-by-0 arrays like '{{}}' and '[4:4][8:7]={{}}', it
> should a
On 1 April 2013 21:57, Robert Haas wrote:
> On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd wrote:
>> On 27 March 2013 06:47, Robert Haas wrote:
>>> rhaas=# select '{}'::int4[] = '{}'::int4[];
>>
>> The good news is, if anybody out there is using
On 2 April 2013 10:59, Robert Haas wrote:
> On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd wrote:
>> It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
>> existing applications, so there is no way for that idiom in existing
>> applications t
On 2 April 2013 11:34, David E. Wheeler wrote:
> On Apr 1, 2013, at 4:59 PM, Robert Haas wrote:
>
>> I think the only people for whom nothing will break are the people who
>> aren't using arrays in the first place. Anyone who is is likely to
>> have dependencies on the way array_lower/upper work
On 4 April 2013 01:10, Tom Lane wrote:
> I think though that the upthread argument that we'd have multiple
> interpretations of the same thing is bogus. To me, the core idea that's
> being suggested here is that '{}' should mean a zero-length 1-D array,
> not a zero-D array as formerly. We would
On 4 April 2013 15:11, Tom Lane wrote:
> Brendan Jurd writes:
>> My thought was that on-disk zero-D arrays should be converted into
>> empty 1-D arrays (with default lower bounds of course) when they are
>> read by array_recv.
>
> Huh? array_recv would not get appl
On 5 April 2013 07:43, Tom Lane wrote:
> Well, if we're going to take that hard a line on it, then we can't
> change anything about array data storage or the existing functions'
> behavior; which leaves us with either doing nothing at all, or
> inventing new functions that have saner behavior whil
On 5 April 2013 13:04, Tom Lane wrote:
> (There's been a remarkable lack of attention to the question
> of spec compliance in this thread, btw. Surely the standard has
> something to say on the matter of zero-length arrays?)
From 4.10 in my draft copy of "Foundation", arrays are one of two
"coll
On 5 April 2013 15:05, Tom Lane wrote:
> Brendan Jurd writes:
>> While I was in there I noticed CARDINALITY, which would be pretty easy
>> to add and would at least provide a more productive way to get the
>> "real" length of an array without disrupting existin
On 6 April 2013 01:59, Kevin Grittner wrote:
> Brendan Jurd wrote:
>
>> The language specifically allows for zero elements, and does not
>> contemplate multiple dimensions.
>
> I don't remember anything in the spec which would prohibit the data
> type of an ar
On 7 April 2013 01:43, Kevin Grittner wrote:
> Brendan Jurd wrote:
>> Indeed it does not prohibit nesting arrays inside other arrays, but
>> the multidim arrays that Postgres allows you to create are not the
>> same thing as nested arrays.
>>
> Your interpretation m
On 8 April 2013 16:09, Tom Lane wrote:
> Brendan Jurd writes:
>> On the specific issue of CARDINALITY, I guess we need to decide
>> whether we are going to pretend that our array/matrix thing is
>> actually nested. I first argued that we should not. But it occurred
&
On 9 April 2013 09:24, Josh Berkus wrote:
> As much as I have a keen interest in this feature, it isn't (AFAIK)
> being considered for 9.3. Given that it's generated a fair amount of
> controversy, could we table it until 9.3 beta? There's still plenty of
> unresolved 9.3 patches in the queue.
On 3 March 2010 14:34, Bruce Momjian wrote:
> Scott Bailey wrote:
>> Tom Lane wrote:
>> > Asher Hoskins writes:
>> >> I can't seem to get to_timestamp() or to_date() to work with quarters,
>> >
>> > The source code says
>> >
>> > * We ignore Q when converting to date because it i
On 4 March 2010 04:08, Tom Lane wrote:
> Brendan Jurd writes:
>> For example, you're trying to import a date that is written as "Wed
>> 3rd March, Q1 2010". You might give to_date a format string like 'Dy
>> FMDDTH Month, "Q"Q ' and ex
On 8 April 2010 06:46, Tom Lane wrote:
> Not a lot of zero suppression happening there :-(.
>
> I believe the correct fix is to reduce the year mod 100 (or 10 or 1000)
> before feeding it to snprintf, rather than playing games with printing
> only part of the result string as the original and curr
Hello hackers,
It turns out that in a PL/PgSQL function, you can DECLARE a variable
using the same name as one of the function parameters. This has the
effect of clobbering the parameter, for example:
CREATE OR REPLACE FUNCTION declare_clobber(foo int)
RETURNS int LANGUAGE plpgsql AS $$
On 15 April 2012 17:55, Pavel Stehule wrote:
> 2012/4/15 Brendan Jurd :
>> It turns out that in a PL/PgSQL function, you can DECLARE a variable
>> using the same name as one of the function parameters. This has the
>> effect of clobbering the parameter, for example:
>>
On 15 April 2012 18:54, Pavel Stehule wrote:
> 2012/4/15 Brendan Jurd :
>> Perhaps it's a failure of imagination on my part, but I can't think of
>> a legitimate reason for a programmer to deliberately use the same name
>> to refer to a declared variable and a
On 18 April 2012 13:44, Tom Lane wrote:
> ... I think you'll find a lot of that data could be mined out of our
> historical commit logs already. I know I make a practice of mentioning
> "bug #" whenever there is a relevant bug number, and I think other
> committers do too. It wouldn't be 100
On 20 May 2012 01:52, Daniel Farina wrote:
> The documentation is misleading to the point of our support for ISO
> 8601-strict parsing.
>
> http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php
>
> A very fine point, but I discovered it not out of curiosity, but a
> fairly angry user o
On 22 May 2012 02:58, Tom Lane wrote:
> Peter Eisentraut writes:
>> The problem is that people think that "ISO" means ISO 8601, whereas it
>> actually means ISO 9075. I can see how that's an easy mistake to make,
>> though.
>
> ... especially since we keep referring to 8601 in our own docs.
> Do
On 24 May 2012 05:30, Peter Eisentraut wrote:
> On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote:
>> I'd be okay with just adding a note in the manual under Date/Time
>> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
>> letter &#
On 23 September 2010 11:28, Abhijit Menon-Sen wrote:
>> This seems pretty dangerous, especially for people who are willing to
>> rely on "git commit -a" :-(
>
> There is no danger. "git commit -a" will commit changes to files that
> match .gitignore but are already in the repository. (I vaguely re
Hi folks,
I have just set up HS+SR for the first time, and for the most part,
the docs were excellent. The one exception for me was the discussion
of archive_cleanup_command. This is a pretty important part of
constructing a healthy standby server, and IMO the docs don't give it
the treatment it
Hi folks,
One of the speedbumps I hit when setting up HS+SR was naming the user
the slave would connect as for streaming replication. At first I
picked 'replication', which seemed quite natural to me (and I don't
doubt will seem natural to others as well).
When I started up the slave, I got this
On 14 October 2010 08:45, Robert Haas wrote:
> Is someone working on a patch?
Yes, I will prepare a patch to get us started.
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
On 12 October 2010 23:28, Fujii Masao wrote:
> On Sat, Oct 9, 2010 at 10:04 AM, Brendan Jurd wrote:
>> I have just set up HS+SR for the first time, and for the most part,
>> the docs were excellent. The one exception for me was the discussion
>> of archive_cleanup_comma
On 15 October 2010 05:33, Simon Riggs wrote:
> On Fri, 2010-10-15 at 02:24 +1100, Brendan Jurd wrote:
>> I'll drop this onto the next open commitfest. If it passes muster, it
>> sure wouldn't hurt to backpatch it to 9.0.
>
> Committed. Not sure there's anyt
On 13 October 2010 00:28, Fujii Masao wrote:
> On Sat, Oct 9, 2010 at 11:13 AM, Brendan Jurd wrote:
>> I understand that 'replication' is a keyword as far as the database
>> name is concerned, but I was surprised to find that it was treated as
>> a keyword in th
On 17 October 2010 01:52, Brendan Jurd wrote:
> Per the above discussion, I've prepared a patch to make keywords in
> pg_hba.conf field-specific.
>
Try New and Improved This Message (tm), now with attachment!
Cheers,
BJ
*** a/src/backend/libpq/hba.c
--- b/src/backe
On 16 October 2010 21:56, Peter Eisentraut wrote:
> As a small addition to the pg_hba.conf host name feature, I figured it
> would be useful to allow "all" in the host column, instead of having to
> write 0.0.0.0/0 and ::/0. Patch attached.
>
Cool. And, for what it's worth, this doesn't conflic
On 17 October 2010 02:27, Alvaro Herrera wrote:
> Hmm. Would it be possible to list keywords _applicable_ to each field,
> and have these passed down to next_token by the caller instead? This
> seems backwards, but I'm not sure if the other way is really workable.
>
Short answer: I don't think
On 17 October 2010 09:59, Tom Lane wrote:
> Brendan Jurd writes:
>> At the time that next_token gets called, we have no way of knowing
>> which field is currently being tokenised, at least not without doing
>> some serious rearrangement of hba.c, so that it tokenises and the
On 19 October 2010 11:16, Josh Berkus wrote:
> 4. I can start a new replica off the master by running a single command-line
> utility on the standby and giving it connection information to the master.
> Using this connection, it should be able to start a backup snapshot, copy
> the entire databas
Hi folks,
In my own databases, I've been using a couple of C functions that
might be useful to the wider community.
They are very simple date/timestamp constructors that take integers as
their arguments. Nothing fancy, but very convenient and *much* faster
than using a SQL or PL/pgSQL workaround
On 23 October 2010 05:58, Peter Geoghegan wrote:
> On 22 October 2010 19:45, Brendan Jurd wrote:
>> Without these functions (or some variation), a user wishing to
>> construct a date from integers can only assemble the date into a
>> string and then put that string throu
On 23 October 2010 06:15, Josh Berkus wrote:
> a) you'd need to rename these.
I'm open to that. What names would you propose?
> b) we'd also want the inverse of these, which would be extremely useful.
Not a problem.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Hi folks,
I have encountered a reproducible segfault in Postgres, and confirmed
it in 9.0.1 and HEAD on three separate machines. The bug was not
present in 8.4. I've attached a copy of the SQL script I have been
using to induce the segfault.
With asserts enabled, I get a failed assertion:
TRAP
On 25 October 2010 07:36, Tom Lane wrote:
> Looks like the invalItems list has been clobbered:
>
> (gdb) p *root->glob->invalItems
> $6 = {type = 2139062143, length = 2139062143, head = 0x7f7f7f7f,
> tail = 0x7f7f7f7f}
>
> I'm guessing it was modified in the temporary memory context and not
> pro
On 25 October 2010 07:36, Tom Lane wrote:
> Brendan Jurd writes:
>> I have encountered a reproducible segfault in Postgres ...
>
> Looks like the invalItems list has been clobbered:
>
> (gdb) p *root->glob->invalItems
> $6 = {type = 2139062143, length = 21390621
On 26 October 2010 03:42, Tom Lane wrote:
> Brendan Jurd writes:
>> Thanks for the hint; I found that the attached patch resolved my
>> specific segfault, but I am wondering whether it goes far enough.
>
> Well, it definitely doesn't go far enough, because the i
On 18 October 2010 01:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 17 October 2010 09:59, Tom Lane wrote:
>>> Good point. Maybe the correct fix is to remember whether each token was
>>> quoted or not, so that keyword detection can be done safely after the
>>
On 6 November 2010 05:46, Josh Berkus wrote:
> I'm continuing in my efforts now to document how to deploy and manage
> replication on our wiki. One of the things a DBA needs to do is to use
> pg_current_xlog_location() (and related functions) to check how far
> behind the master the standby is.
>
On 29 May 2011 14:04, Tom Lane wrote:
> Anything that even pretends to be a bug tracker will do that. The
> real question is, who is going to keep it up to date? GSM has the
> right point of view here: we need at least a couple of people who
> are willing to invest substantial amounts of time, o
On 31 May 2011 11:52, Robert Haas wrote:
> I have used RT and I found that the
> web interface was both difficult to use and unwieldly for tickets
> containing large numbers of messages.
A big loud "ditto" from me on this point.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Hi folks,
I was working on a little docs patch today, and when I tried to
`make`, openjade choked on an identifier in information_schema.sgml,
which is very much unrelated to my changes:
openjade:information_schema.sgml:828:60:Q: length of name token must
not exceed NAMELEN (44)
Here is a trivia
On 1 June 2011 06:36, Peter Eisentraut wrote:
> It looks like the original DocBook distribution has a limit of 44, but
> someone patched it to 256 on your installation.
>
> But it seems like no one else has seen this problem yet, so it's quite
> suspicious, since surely people have built the docum
On 16 June 2011 00:22, Pavel Stehule wrote:
> I try to apply your patch, but it is finished with some failed hinks.
>
> Please, can you refresh your patch
Hi Pavel,
Thanks for taking a look. I have attached v2 of the patch, as against
current HEAD. I've also added the new patch to the CF app.
On 22 May 2011 07:27, Fabien COELHO wrote:
>
> Hello Tom,
>
>>> Add "AS EXPLICIT" to "CREATE CAST" This gives a name to the default case
>>> of "CREATE CAST", which creates a cast which must be explicitely invoked.
>>
>> I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
>> st
On 18 June 2011 13:43, Alvaro Herrera wrote:
> Is this really a WIP patch? I'm playing a bit with it currently, seems
> fairly sane.
>
In this case, the WIP designation is meant to convey "warning: only
casual testing has beeen done". I tried it out with various
permutations of pg_hba.conf, and
On 21 June 2011 06:06, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of lun jun 20 12:19:37 -0400 2011:
>> Excerpts from Pavel Stehule's message of lun jun 20 11:34:25 -0400 2011:
>>
>> > b) probably you can simplify a memory management using own two
>> > persistent memory context
On 21 June 2011 11:11, Alvaro Herrera wrote:
> I realize I took out most of the fun of this patch from you, but -- are
> you still planning to do some more exhaustive testing of it? I checked
> some funny scenarios (including include files and groups) but it's not
> all that unlikely that I misse
On 21 June 2011 13:51, Pavel Stehule wrote:
> I have one question. I can't find any rules for work with tokens, etc,
> where is quotes allowed and disallowed?
>
> I don't see any other issues.
I'm not sure I understand your question, but quotes are allowed
anywhere and they always act to remove a
On 21 June 2011 14:34, Pavel Stehule wrote:
> I don't understand to using a macro
>
> #define token_is_keyword(t, k) (!t->quoted && strcmp(t->string, k) == 0)
>
> because you disallowed a quoting?
Well, a token can only be treated as a special keyword if it is unquoted.
As an example, in the 'd
On 22 June 2011 00:47, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>>> because >>pamservice<< - is known keyword, but 'pamservice' is some
>>> literal without any mean. You should to use a makro token_is_keyword
>>> more oft
On 22 June 2011 14:01, Pavel Stehule wrote:
> ook, now is clean, so this is majority opinion.
>
> Please, can you send a final patch.
I don't have any further changes to add to Alvaro's version 3, which
is already up on the CF app.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On 24 June 2011 03:48, Alvaro Herrera wrote:
> I have touched next_token() and next_token_expand() a bit more, because
> it seemed to me that they could be simplified further (the bit about
> returning the comma in the token, instead of being a boolean return,
> seemed strange). Please let me kno
1 - 100 of 513 matches
Mail list logo
