Re: [HACKERS] psql: Activate pager only for height, not width

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

[HACKERS] psql: Activate pager only for height, not width

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

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

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

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

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

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

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

Re: [HACKERS] psql: add \pset true/false

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

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Thu, 16 Jul 2015 at 08:37 Gurjeet Singh gurj...@singh.im 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

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Fri, 17 Jul 2015 at 23:14 Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Fri, 26 Jun 2015 at 06:03 Gurjeet Singh gurj...@singh.im 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

Re: [HACKERS] Tab completion for TABLESAMPLE

On Fri, 19 Jun 2015 at 21:05 Petr Jelinek p...@2ndquadrant.com 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 to be valid

Re: [HACKERS] Tab completion for TABLESAMPLE

On Sun, 14 Jun 2015 at 20:44 Petr Jelinek p...@2ndquadrant.com 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

Re: [HACKERS] Tab completion for CREATE SEQUENCE

On Tue, 16 Jun 2015 at 00:52 Vik Fearing v...@2ndquadrant.fr 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

Re: [HACKERS] proposal: row_to_array function

On Thu, 2 Apr 2015 at 05:00 Merlin Moncure mmonc...@gmail.com wrote: On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Thu, 18 Jun 2015 at 03:06 Gurjeet Singh gurj...@singh.im 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

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

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 /row row +

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Thu, 18 Jun 2015 at 08:19 Merlin Moncure mmonc...@gmail.com 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

[HACKERS] [PATCH] Function to get size of asynchronous notification queue

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,

Re: [HACKERS] Function to get size of notification queue?

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 tumbleweed/ response to my original email,

Re: [HACKERS] Function to get size of notification queue?

On Tue, 16 Jun 2015 at 05:36 Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Brendan Jurd wrote: However, given the tumbleweed/ response to my original email, it's likely that effort would be a waste of time. I

Re: [HACKERS] Function to get size of notification queue?

On Tue, 16 Jun 2015 at 07:52 Merlin Moncure mmonc...@gmail.com 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.

Re: [HACKERS] Minimum supported version of Python?

On 16 March 2014 11:55, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] proposal: simple date constructor from numeric values

On 1 July 2013 17:47, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/6/29 Pavel Stehule pavel.steh...@gmail.com: 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

Re: [HACKERS] proposal: simple date constructor from numeric values

On 3 July 2013 21:41, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 25 June 2013 04:13, Joshua D. Drake j...@commandprompt.com 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

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com 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

Re: [HACKERS] Hard to Use WAS: Hard limit on WAL space

On 15 June 2013 14:43, Craig Ringer cr...@2ndquadrant.com 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

Re: [HACKERS] Hard to Use WAS: Hard limit on WAL space

On 15 June 2013 16:18, Craig Ringer cr...@2ndquadrant.com wrote: On 06/15/2013 02:08 PM, Brendan Jurd wrote: On 15 June 2013 14:43, Craig Ringer cr...@2ndquadrant.com wrote: The #1 question I see on Stack Overflow has to be confusion about pg_hba.conf, mostly from people who have no idea

Re: [HACKERS] [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 14 June 2013 03:53, David E. Wheeler da...@justatheory.com wrote: Similar things should have dissimilar names. I propose: bikeshedding Old |New --+-- array_dims | array_desc array_bounds? array_ndims | array_depth array_length | array_size

Re: [HACKERS] [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 12 June 2013 18:22, Dean Rasheed dean.a.rash...@gmail.com 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

Re: [HACKERS] [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 13 June 2013 04:26, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com 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()

[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 12 June 2013 04:43, Josh Berkus j...@agliodbs.com 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

Re: [HACKERS] 9.3: Empty arrays returned by array_remove()

On 31 May 2013 02:52, Dean Rasheed dean.a.rash...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 8 April 2013 16:09, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com 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

[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 9 April 2013 09:24, Josh Berkus j...@agliodbs.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 7 April 2013 01:43, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com 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 matches

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 6 April 2013 01:59, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com 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 array element

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 07:43, Tom Lane t...@sss.pgh.pa.us 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 13:04, Tom Lane t...@sss.pgh.pa.us 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com 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 existing

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 01:10, Tom Lane t...@sss.pgh.pa.us 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 15:11, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com 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 applied

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 1 April 2013 21:57, Robert Haas robertmh...@gmail.com wrote: On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd dire...@gmail.com wrote: On 27 March 2013 06:47, Robert Haas robertmh...@gmail.com wrote: rhaas=# select '{}'::int4[] = '{}'::int4[]; The good news is, if anybody out there is using

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2 April 2013 10:59, Robert Haas robertmh...@gmail.com wrote: On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd dire...@gmail.com 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 to be broken

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2 April 2013 11:34, David E. Wheeler da...@kineticode.com wrote: On Apr 1, 2013, at 4:59 PM, Robert Haas robertmh...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 20:34, Dean Rasheed dean.a.rash...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 00:21, Dean Rasheed dean.a.rash...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 09:39, Dean Rasheed dean.a.rash...@gmail.com wrote: On 27 March 2013 17:14, Brendan Jurd dire...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 22:57, Robert Haas robertmh...@gmail.com 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 27 March 2013 06:47, Robert Haas robertmh...@gmail.com wrote: On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd dire...@gmail.com 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. rhaas

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 00:30, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On 25 March 2013 13:02, Josh Berkus j...@agliodbs.com wrote: Brendan, how hard would it be to create a GUC for backwards-compatible behavior? Good idea. No, it *isn't* a good idea. GUCs

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 21 March 2013 10:45, Brendan Jurd dire...@gmail.com 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, sans

[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)

On 26 March 2013 05:26, Greg Stark st...@mit.edu 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

Re: [HACKERS] adding support for zero-attribute unique/etc keys

On 26 March 2013 05:04, Darren Duncan dar...@darrenduncan.net 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

Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 25 March 2013 13:02, Josh Berkus j...@agliodbs.com 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 they return meaningful

Re: [HACKERS] Single-argument variant for array_length and friends?

On 22 March 2013 09:12, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Mar 21, 2013 at 2:00 AM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Single-argument variant for array_length and friends?

On 21 March 2013 17:08, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/3/21 Tom Lane t...@sss.pgh.pa.us: 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

Re: [HACKERS] Single-argument variant for array_length and friends?

On 21 March 2013 17:32, Pavel Stehule pavel.steh...@gmail.com 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,

[PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 17 March 2013 05:19, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On 16 March 2013 09:07, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Should array_length() Return NULL

On 16 March 2013 09:07, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@justatheory.com 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

Re: [HACKERS] Should array_length() Return NULL

On 17 March 2013 05:19, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On 16 March 2013 09:07, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Should array_length() Return NULL

On 17 March 2013 06:27, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Considering Gerrit for CFs

On 7 February 2013 08:07, Josh Berkus j...@agliodbs.com 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

[HACKERS] Function to get size of notification queue?

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

Re: [HACKERS] operator dependency of commutator and negator, redux

On 20 December 2012 11:51, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] External Open Standards

On 24 May 2012 05:30, Peter Eisentraut pete...@gmx.net 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 'T' to separate the date and time

Re: [HACKERS] External Open Standards

On 22 May 2012 02:58, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] External Open Standards

On 20 May 2012 01:52, Daniel Farina dan...@heroku.com 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

Re: [HACKERS] Bug tracker tool we need

On 18 April 2012 13:44, Tom Lane t...@sss.pgh.pa.us 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

[HACKERS] Clobbered parameter names via DECLARE in PL/PgSQL

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 $$

Re: [HACKERS] Clobbered parameter names via DECLARE in PL/PgSQL

On 15 April 2012 17:55, Pavel Stehule pavel.steh...@gmail.com wrote: 2012/4/15 Brendan Jurd dire...@gmail.com: 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

Re: [HACKERS] Clobbered parameter names via DECLARE in PL/PgSQL

On 15 April 2012 18:54, Pavel Stehule pavel.steh...@gmail.com wrote: 2012/4/15 Brendan Jurd dire...@gmail.com: 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

Re: [HACKERS] Our regex vs. POSIX on longest match

On 5 March 2012 17:23, Robert Haas robertmh...@gmail.com 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,

Re: [HACKERS] Our regex vs. POSIX on longest match

On 4 March 2012 17:53, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com 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 POSIX

Re: [HACKERS] Our regex vs. POSIX on longest match

On 5 March 2012 04:34, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On 4 March 2012 17:53, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: While it's true that POSIX doesn't contemplate non-greed, after reading the spec I would have

[HACKERS] Our regex vs. POSIX on longest match

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

Re: [HACKERS] Future of our regular expression code

On 19 February 2012 15:49, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Future of our regular expression code

On 20 February 2012 10:42, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Future of our regular expression code

On 19 February 2012 06:52, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Arithmetic operators for macaddr type

On 12 December 2011 15:59, Pavel Stehule pavel.steh...@gmail.com wrote: 2011/12/12 Brendan Jurd dire...@gmail.com: 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

[HACKERS] Arithmetic operators for macaddr type

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

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

On 1 November 2011 00:14, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Is there really no interest in SQL Standard?

On 16 September 2011 16:24, Susanne Ebrecht susa...@2ndquadrant.com 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

Re: [HACKERS] Moving core timestamp typedefs/macros somewhere else

On 8 September 2011 10:22, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] postgresql.conf archive_command example

On 31 August 2011 04:39, Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] [BUGS] extract(epoch from infinity) is not 0

On 14 July 2011 06:58, Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] [BUGS] extract(epoch from infinity) is not 0

On 14 July 2011 08:16, Robert Haas robertmh...@gmail.com wrote: On Jul 13, 2011, at 4:21 PM, Brendan Jurd dire...@gmail.com 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 have

Re: [HACKERS] minor patch submission: CREATE CAST ... AS EXPLICIT

On 18 June 2011 09:49, Brendan Jurd dire...@gmail.com 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/create_cast.sgml:20

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 24 June 2011 03:48, Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 22 June 2011 00:47, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 22 June 2011 14:01, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 21 June 2011 06:06, Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 21 June 2011 11:11, Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 21 June 2011 13:51, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 21 June 2011 14:34, Pavel Stehule pavel.steh...@gmail.com 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

[HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 16 June 2011 00:22, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] minor patch submission: CREATE CAST ... AS EXPLICIT

On 22 May 2011 07:27, Fabien COELHO coe...@cri.ensmp.fr 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

Re: [HACKERS] Fwd: Keywords in pg_hba.conf should be field-specific

On 18 June 2011 13:43, Alvaro Herrera alvhe...@commandprompt.com 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

[HACKERS] DOCS: SGML identifier may not exceed 44 characters

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

Re: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters

On 1 June 2011 06:36, Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Getting a bug tracker for the Postgres project

On 31 May 2011 11:52, Robert Haas robertmh...@gmail.com 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

  1   2   3   4   5   6   >