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
As an extra data point, if you try this in Python (psycopg2) you get an
exception:
psycopg2.ProgrammingError: autocommit cannot be used inside a transaction
I think this exception is a legitimate response. If the user switches on
autocommit mode inside a transaction, it was most likely not on pu
On Tue, 22 Mar 2016 at 10:34 Robert Haas wrote:
> Yeah, I think requiring PERFORM is stupid and annoying. +1 for
> letting people write a SELECT with no target.
>
Apologies for being late on the thread, but another +1 from me. I've often
been frustrated by the dissonance of PERFORM against SQL
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 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 Fri, 17 Jul 2015 at 23:14 Robert Haas wrote:
> Committed. I changed one remaining use of "proportion" to "fraction",
> fixed an OID conflict, and reverted some unnecessary whitespace
> changes.
>
Thanks Robert. Sorry I missed a "proportion" in my latest version, and
thanks for catching it.
On Thu, 16 Jul 2015 at 08:37 Gurjeet Singh wrote:
> OK. Please send a new patch with the changes you agree to, and I can mark
> it ready for committer.
>
Done. Please find attached patch v3. I have changed "proportion" to
"fraction", and made other wording improvements per your suggestions.
C
On Fri, 26 Jun 2015 at 06:03 Gurjeet Singh wrote:
> Patch reviewed following the instructions on
> https://wiki.postgresql.org/wiki/Reviewing_a_Patch
>
>
Thank you for your review, Gurjeet.
> s/proportion/fraction/
>
I think of these as synonymous -- do you have any particular reason to
prefe
On Fri, 19 Jun 2015 at 21:05 Petr Jelinek wrote:
> On 2015-06-19 09:08, Brendan Jurd wrote:
> > I
> > think it would be convenient and user-friendly to complete the opening
> > bracket -- it would make it perfectly clear that an argument is required
> > for the syntax
On Sun, 14 Jun 2015 at 20:44 Petr Jelinek wrote:
> looks like I omitted psql tab completion from the TABLESAMPLE patch. The
> attached patch adds it.
>
Hi Petr,
I'm doing an initial review of this patch.
It applies and compiles cleanly. Code style is consistent with its
surroundings.
With th
On Tue, 16 Jun 2015 at 00:52 Vik Fearing wrote:
> While reviewing the seqam patches, I noticed that psql has tab
> completion for ALTER SEQUENCE, but not for CREATE SEQUENCE.
>
> The attached trivial patch fixes that.
>
Hi Vik,
I'm doing an initial review of this patch.
It applies cleanly, alt
On Thu, 2 Apr 2015 at 05:00 Merlin Moncure wrote:
> On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane wrote:
> > While I don't have a problem with hstore_to_array, I don't think that
> > row_to_array is a very good idea; it's basically encouraging people to
> > throw away SQL datatypes altogether and im
Posting v2 of the patch, incorporating some helpful suggestions from Merlin.
Cheers,
BJ
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 14800,14805 SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
--- 14800,14811
+pg_noti
On Thu, 18 Jun 2015 at 08:19 Merlin Moncure wrote:
>
> scratch that. that note already exists in sql-notify.html. Instead,
> I'd modify that section to note that you can check queue usage with
> your new function.
>
>
I have already done so. Under the paragraph about the queue filling up, I
ha
On Thu, 18 Jun 2015 at 03:06 Gurjeet Singh wrote:
> I don't see this in the CF app; can you please add it there?
>
Done. I did try to add it when I posted the email, but for some reason I
couldn't connect to commitfest.postgresql.org at all. Seems fine now,
though.
Cheers,
BJ
Hello hackers,
I present a patch to add a new built-in function
pg_notify_queue_saturation().
The purpose of the function is to allow users to monitor the health of
their notification queue. In certain cases, a client connection listening
for notifications might get stuck inside a transaction, a
On Tue, 16 Jun 2015 at 07:52 Merlin Moncure wrote:
> It goes back to the adage, 'Everyone wants to be an author but nobody
> wants to write'.
A more accurate version would be "Everyone wants to be an author, some want
to write, but nobody likes being rejected by publishers".
> For posterity,
On Tue, 16 Jun 2015 at 05:36 Merlin Moncure wrote:
> On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
> wrote:
> > Brendan Jurd wrote:
> >> However, given the response to my original email,
> >> it's likely that effort would be a waste of time.
> >
>
Hi Kevin,
I never found a direct solution to this problem. I still feel that a
function to find the size of the notification queue would be a handy
feature to have, and I would be willing to take a shot at writing such a
feature. However, given the response to my original email,
it's likely tha
On 16 March 2014 11:55, Tom Lane wrote:
> Our documentation claims that the minimum Python version for plpython
> is 2.3. However, an attempt to build with that on an old Mac yielded
> a bunch of failures in the plpython_types regression test, all of the
> form
>
...
> Personally I have no desire
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
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 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
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 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 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 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 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 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:
>>
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 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 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 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
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 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
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 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 12 December 2011 15:59, Pavel Stehule wrote:
> 2011/12/12 Brendan Jurd :
>> I just bumped into a situation where I wanted to do a little macaddr
>> arithmetic in postgres. I note that the inet type has support for
>> bitwise AND, OR and NOT, as well as subtraction, but m
Hello folks,
I just bumped into a situation where I wanted to do a little macaddr
arithmetic in postgres. I note that the inet type has support for
bitwise AND, OR and NOT, as well as subtraction, but macaddr has none
of the above.
These operations are easy to perform in C, but relatively a pain
On 1 November 2011 00:14, Andrew Dunstan wrote:
> On 10/30/2011 10:00 PM, Christopher Browne wrote:
>> I don't think I wish it. We're telling our developers not to use "select
>> *", and I don't think having "select * except " would change that policy,
>> beyond requiring us to waste time explain
On 16 September 2011 16:24, Susanne Ebrecht wrote:
> Isn't it possible to create a closed mailing list - a list that won't get
> published - on which
> I can discuss SQL Standard stuff with the folk who wants to support me?
>
> I don't fear to make decisions on my own - but speaking for the whole
On 8 September 2011 10:22, Tom Lane wrote:
> If you believe the idea I suggested a few days ago that we ought to try
> to push basic typedefs into a separate set of headers, then this could
> be the first instance of that, which would lead to naming it something
> like "datatype/timestamp.h". If
On 31 August 2011 04:39, Peter Eisentraut wrote:
> I think it would be useful to add the following explanation and sample
> to the postgresql.conf sample file:
>
Good idea Peter, +1.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 14 July 2011 08:16, Robert Haas wrote:
> On Jul 13, 2011, at 4:21 PM, Brendan Jurd wrote:
>> Well, for example, how do you go about answering the question "what is
>> the day-of-month of the infinite timestamp?" The question is
>> nonsense; it doesn't hav
On 14 July 2011 06:58, Alvaro Herrera wrote:
> I don't find the proposed behavior all that suprising, which the
> original behavior surely is. I guess the bigger question is whether the
> values that timestamptz_part() returns for other cases (than epoch)
> should also be different from 0 when an
On 18 June 2011 09:49, Brendan Jurd wrote:
> Hi Fabien,
>
> I'm taking a look at this patch for the commitfest. On first reading
> of the patch, it looked pretty sensible to me, but I had some trouble
> applying it to HEAD:
>
> error: patch failed: doc/src/sgml/ref/c
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
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 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 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 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 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 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 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 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 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 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
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
1 - 100 of 513 matches
Mail list logo
