On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski
wrote:
> But then it becomes disputable if SQL syntax change makes sense.
>
> ---we had this,
> NOTIFY channel [ , payload ]
> ---and in this patch we have this
> NOTIFY [ ALL | DISTINCT ] channel [ , payload ]
> --- but maybe we should have t
On Tue, May 27, 2014 at 10:01 PM, Gurjeet Singh wrote:
> When the Postgres server is being stopped/shut down, the `Buffer
> Saver` scans the
> shared-buffers of Postgres, and stores the unique block identifiers of
> each cached
> block to the disk. This information is saved under the
> `$PGDATA/
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan wrote:
> On 05/29/2014 02:38 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>> Interesting. Looks like you have access only to virtual network
>> interfaces, and they report all-zero MAC addresses, which the UUID library
On Wed, May 28, 2014 at 11:23 PM, Tom Lane wrote:
> Buildfarm critters smew and shearwater are reporting regression test
> failures that suggest that the UUID library can't get a system MAC
> address:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=smew&dt=2014-05-28%2023%3A38%3A28
> http
On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt wrote:
> Also, Pavel, this patch is still listed as 'Needs Review' in the CF
> app, but I haven't seen a response to the concerns in my last message.
It looks like this patch has been imported into the 2013-11 CF [1] and
mar
On Thu, Oct 10, 2013 at 12:54 PM, Andrew Dunstan wrote:
> This thread seems to have gone cold, but I'm inclined to agree with Pavel.
> If the table doesn't exist, neither does the trigger, and the whole point of
> the 'IF EXISTS' variants is to provide the ability to issue DROP commands
> that do
On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas
wrote:
> Assuming no objections, I'll apply the attached patch to 9.3 and master
> later tonight.
Just a little stylistic nitpick: could we pluralize the --help outputs
for the modified options so that they make clear that multiple
specification
On Tue, Jul 2, 2013 at 7:47 AM, Pavel Stehule wrote:
> Hello
>
> remastered patch
>
> still there is a issue with dependencies
Several of the issues from my last review [1] seem to still be present
in this patch, such as review notes #1 and #4.
And as discussed previously, I think that the --cle
Hi all,
Is there any reason not to tab-complete the local filename used by the
\lo_import command? Small patch to do so attached.
Josh
tab_complete_lo_import.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Jul 2, 2013 at 5:39 AM, Pavel Stehule wrote:
> 2013/3/8 Josh Kupershmidt :
>> On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule
>> wrote:
>>> 2013/3/8 Josh Kupershmidt :
>>
>>>> Cool. I think it would also be useful to check that --clean may only
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule wrote:
> I am sending a patch that removes strict requirements for DROP IF
> EXISTS statements. This behave is similar to our ALTER IF EXISTS
> behave now.
+1 for this idea. But this patch should be treated as a separate issue
from the use of IF EXI
On Mon, Nov 12, 2012 at 5:14 PM, Andrew Dunstan wrote:
> vacuumlo is rather simpleminded about dealing with the list of LOs to be
> removed - it just fetches them as a straight resultset. For one of my our
> this resulted in an out of memory condition.
Wow, they must have had a ton of LOs. With a
On Thu, Jun 27, 2013 at 11:47 AM, Fujii Masao wrote:
> On Thu, Jun 27, 2013 at 10:36 AM, Josh Kupershmidt wrote:
>> On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao wrote:
>>> Though this is a corner case, the patch doesn't seem to handle properly the
>>> case
On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao wrote:
> On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu wrote:
>> On June 26, 2013 5:02 AM Josh Kupershmidt wrote:
>>>Thanks for the feedback. Attached is a rebased version of the patch with
>> the two small issues noted
On Tue, Jun 25, 2013 at 2:28 AM, Hari Babu wrote:
> Please find the review of the patch.
Thank you for reviewing!
> Code Review:
>
> +if (orig_post_opts) {
> +post_opts = strip_datadirs(orig_post_opts);
> +}
>
> No need of "{}" as the only one statement block is present in t
On Tue, Jun 18, 2013 at 12:42 PM, Jeff Davis wrote:
> Attached a new diff for pg_filedump that makes use of the above change.
>
> I'm not sure what the resolution of Alvaro's concern was, so I left the
> flag reporting the same as the previous patch.
This patch is in the current CommitFest, does
On Mon, Jun 24, 2013 at 12:57 PM, Josh Berkus wrote:
> Actually, every submitter on that list -- including Maciej -- was sent a
> personal, private email a week ago. A few (3) chose to take the
> opportunity to review things, or promised to do so, including a brand
> new Chinese contributor who n
Hi all,
I have a Debian machine with gcc 4.7.2-5 where make check-world fails
in the isolation check, like so:
...
make[2]: Leaving directory `/home/josh/src/postgresql/src/test/regress'
make -C isolation check
[snip]
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-stateme
On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule wrote:
> I'll see - please, stay tuned to 9.4 first commitfest
Hi Pavel,
Just a reminder, I didn't see this patch in the current commitfest. I
would be happy to spend some more time reviewing if you wish to pursue
the patch.
Josh
--
Sent via pgs
On Fri, Mar 22, 2013 at 9:35 PM, Joshua D. Drake wrote:
> postgres@jd-laptop:~$ pg_restore -d test -P 'by(),hello()' foo.sqlc
Note, the pg_restore doc makes no mention of trying to squeeze
multiple function prototypes in a single argument you've done here, or
of using multiple -P flags.
> It ap
On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote:
> On 20 March 2013 02:51, Michael Paquier wrote:
>
>> If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
>> with invalid indexes. I don't think that the user would like to see invalid
>> indexes of
>> an existing system be
On Mon, Mar 18, 2013 at 3:10 PM, Robins Tharakan wrote:
> Hi,
>
> Please find an updated patch (reworked on the names of SEQUENCES / ROLES /
> SCHEMA etc.)
> Takes code-coverage of 'make check' for SEQUENCE to ~95%.
There is a typo difference between sequence.out and sequence.sql
causing the test
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule wrote:
> 2013/3/8 Josh Kupershmidt :
>> Cool. I think it would also be useful to check that --clean may only
>> be used with --format=p to avoid any confusion there. (This issue
>> could be addressed in a separate patch if you&#
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule wrote:
> so
>
> * --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting this example to work (after setting up the regression
database with `make install
On Mon, Mar 4, 2013 at 11:54 AM, Stephen Frost wrote:
> Yeah, no, I don't think we should go in this direction. The whole
> TraceQuery thing is entirely redundant to what's already there and which
> should have been used from the beginning. This would be adding on to
> that mistake instead of fi
On Mon, Mar 4, 2013 at 11:39 AM, Stephen Frost wrote:
> Josh,
>
> * Josh Kupershmidt (schmi...@gmail.com) wrote:
>> I still think this patch is an improvement over the status quo, and is
>> committable as-is. Yes, the patch doesn't address the existing
>> ugliness
On Wed, Feb 27, 2013 at 12:09 PM, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I don't agree so it works well - you cannot use short type names is
>> significant issue
>
> This is for psql. In what use-case do you see that being a serious
> limitation?
>
> I might su
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule wrote:
> 2013/1/14 Tom Lane :
>> Well, fine, but then it should fix both of them and remove
>> minimal_error_message altogether. I would however suggest eyeballing
>> what happens when you try "\ef nosuchfunction" (with or without -E).
>> I'm pretty
There have been some complaints[1][2] in the past about pg_ctl not
playing nice with relative path specifications for the datadir. Here's
a concise illustration:
$ mkdir /tmp/mydata/ && initdb /tmp/mydata/
$ cd /tmp/
$ pg_ctl -D ./mydata/ start
$ cd /
$ pg_ctl -D /tmp/mydata/ restart
IM
On Tue, Jan 15, 2013 at 6:35 PM, Jeff Janes wrote:
> Do you propose back-patching this? You could argue that this is a bug in
> 9.1 and 9.2. Before that, they generate deprecation warnings, but do not
> give the wrong answer.
I think that backpatching to 9.1 would be reasonable, though I won'
On Mon, Jan 7, 2013 at 8:12 PM, Peter Eisentraut wrote:
> On Sat, 2013-01-05 at 15:34 +0100, Magnus Hagander wrote:
>> On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt wrote:
>> > I propose slimming down the pg_dump README, keeping intact the
>> > introductory notes an
On Sat, Jan 5, 2013 at 7:34 AM, Magnus Hagander wrote:
> On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt wrote:
> Do we need to keep it at all, really? Certainly the introductory part
> is covered in the main documentation already...
Pretty much. (I did find note #2 mildly interesti
The ./src/bin/pg_dump README contains several inoperable examples.
First, this suggestion:
| or to list tables:
|
| pg_restore --table | less
seems bogus, i.e. the --table option requires an argument specifing
which table to restore, and does not "list tables". Next, this
suggested comma
On Thu, Dec 20, 2012 at 1:26 AM, Gavin Flower
wrote:
> On 20/12/12 14:57, Josh Kupershmidt wrote:
>
> CREATE TABLE test (id int);
> CREATE INDEX test_idx1 ON test (id);
> CREATE INDEX test_idx2 ON test (id);
>
> I initially misread your example code, but after I realised my
I recently came across a scenario like this (tested on git head):
CREATE TABLE test (id int);
CREATE INDEX test_idx1 ON test (id);
CREATE INDEX test_idx2 ON test (id);
CREATE TABLE test_copycat (LIKE test INCLUDING ALL);
\d test_copycat
Why do we end up with only one index on test_copy
On Sun, Dec 2, 2012 at 4:37 AM, Alastair Turner wrote:
> Patch for the changes discussed in
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
> attached (eventually ...)
>
> In summary: If the input file (-f) doesn't exist or the ouput or log
> files (-o and -l) can't be created
On Thu, Dec 13, 2012 at 9:03 PM, Karl O. Pinc wrote:
> My brain seems to have turned itself on. I went and (re)read
> the docbook manual and was able to come up with this,
> which works:
>
>
>
>
>--table
>-t
>
> table
>
> Yay! (indentation et-al aside)
That
On Thu, Dec 13, 2012 at 7:24 PM, Karl O. Pinc wrote:
> The problem is that the pg man pages would then have a
> syntax different from all the other man pages in the system,
> which all have ... outside of square braces.
> See "man cat", e.g.
FWIW, `man cat` on my OS X machine has synopsis:
On Thu, Dec 13, 2012 at 6:05 AM, Karl O. Pinc wrote:
> On 12/13/2012 12:35:14 AM, Karl O. Pinc wrote:
>
>> On 12/12/2012 11:04:53 PM, Josh Kupershmidt wrote:
>> > On Wed, Dec 12, 2012 at 8:14 AM, Karl O. Pinc wrote:
>> > > On 12/11/2012 10:25:43 PM, Josh Kupershm
On Wed, Dec 12, 2012 at 8:14 AM, Karl O. Pinc wrote:
> On 12/11/2012 10:25:43 PM, Josh Kupershmidt wrote:
>> On Tue, Dec 11, 2012 at 11:46 AM, Karl O. Pinc wrote:
>> >> I believe you need ellipses behind --table in the syntax summaries
>> >> of the command
; simply undocumented what pg_restore does when
> given repeated, conflicting, arguments and we're
> free to change this. Any thoughts?
Agreed with Robert that this change should be reasonable in a major
version (i.e. 9.3).
> On 12/10/2012 09:23:03 PM, Karl O. Pinc wrote:
>>
On Tue, Dec 11, 2012 at 6:01 PM, David Gould wrote:
>
> I'm sure I've had a stroke or something in the middle of the night and just
> didn't notice, but I'm able to reproduce the following on three different
> hosts on both 9.2.1 and 9.2.2. As far as I know the only difference between
> these quer
On Tue, Dec 11, 2012 at 5:18 AM, Boszormenyi Zoltan wrote:
> 2012-12-11 12:45 keltezéssel, Simon Riggs írta:
>
>> On 11 December 2012 10:39, Marko Kreen wrote:
>>>
>>> On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt
>>> wrote:
>>>>
>>&
The documentation for PQclear() doesn't say whether it is safe to call
PQclear() more than once on the same PGresult pointer. In fact, it is
not safe, but apparently only because of this last step:
/* Free the PGresult structure itself */
free(res);
The other members of PGresult which may
Sorry for the delay in following up here.
On Mon, Nov 26, 2012 at 8:30 PM, Karl O. Pinc wrote:
> On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
>> On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas
>> wrote:
>> > On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
&g
On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas wrote:
> On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
>> P.S. An outstanding question regards --truncate-tables
>> is whether it should drop indexes before truncate
>> and re-create them after restore. Sounds like it should.
>
> Well, that wo
On Wed, Nov 21, 2012 at 5:48 AM, Karl O. Pinc wrote:
>> On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
>> > On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> OT:
> After looking at the code I found a number of "conflicting"
> option combinations are not tested for or rejected. I can't
>
Hi Karl,
I signed on to review this patch for the current CF. Most of the
background for the patch seems to be in the message below, so I'm
going to respond to this one first.
On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
> On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
>
>> I've had probl
On Sun, Oct 28, 2012 at 4:30 PM, Josh Kupershmidt wrote:
> I see there's already a TODO for allowing pg_restore to accept
> multiple --table arguments[1], but would folks support adding this
> capability to various other commands which currently accept only a
> single --table
Hi all,
I see there's already a TODO for allowing pg_restore to accept
multiple --table arguments[1], but would folks support adding this
capability to various other commands which currently accept only a
single --table argument, such as clusterdb, vacuumdb, and reindexdb?
Looking at pg_dump, it
Hi all,
It seems the queries in ./src/tutorial/syscat.source use string
escaping with the assumption that standard_conforming_strings is off,
and thus give wrong results with modern versions. A simple fix is
attached.
Josh
syscat.source_escaping.diff
Description: Binary data
--
Sent via pgsql-h
On Thu, Sep 20, 2012 at 8:33 PM, Michael Paquier
wrote:
> On Fri, Sep 21, 2012 at 12:07 PM, Josh Kupershmidt
> wrote:
>>
>> On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
>> wrote:
> What could be also great is to move the project directly into github to
>
On Thu, Sep 20, 2012 at 7:05 PM, Michael Paquier
wrote:
> Hi all,
>
> During the last PGCon, I heard that some community members would be
> interested in having pg_reorg directly in core.
I'm actually not crazy about this idea, at least not given the current
state of pg_reorg. Right now, there ar
On Tue, Jul 10, 2012 at 2:09 AM, Colin 't Hart wrote:
> Attached please find a trivial patch for psql which adds a \n meta command
> as a shortcut for typing set search_path =.
I think the use-case is a bit narrow: saving a few characters typing
on a command not everyone uses very often (I don't)
On Sat, Jul 7, 2012 at 5:43 PM, Noah Misch wrote:
> I like the patch, as far as it goes. It's the natural addition to the
> completions we already offer; compare the simplistic completion after WHERE.
> Like Pavel and Robert, I think a delightful implementation of tab completion
> for SELECT stat
On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule wrote:
> I tested Peter's patch and it works well.
I liked it as well. But I'm not sure what should happen with the patch
now. It seems like it'd be commit-ready with just a tweak or two to
the query as I noted in my last mail, but Tom did seem oppos
On Tue, Jul 3, 2012 at 6:57 AM, Robert Haas wrote:
> Here's a patch that attempts to begin the work of adjusting the
> documentation for this brave new world. I am guessing that there may
> be other places in the documentation that also require updating, and
> this page probably needs more work,
On Thu, Jun 28, 2012 at 6:48 AM, Noah Misch wrote:
> On Thu, Jun 28, 2012 at 01:36:49AM -0700, Daniel Farina wrote:
>> On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt wrote:
>> > I have one nitpick related to the recent changes for
>> > pg_cancel_backend() and pg_
Hi all,
I have one nitpick related to the recent changes for
pg_cancel_backend() and pg_terminate_backend(). If you use these
functions as an unprivileged user, and try to signal a nonexistent
PID, you get:
ERROR: must be superuser or have the same role to cancel queries
running in other serve
On Tue, Jun 19, 2012 at 4:31 AM, Peter Eisentraut wrote:
> On ons, 2012-01-18 at 21:21 +0200, Peter Eisentraut wrote:
>> On lör, 2012-01-07 at 16:41 -0500, Tom Lane wrote:
>> > Peter Eisentraut writes:
>> > > I suggest that we change PostgresMain(), PostmasterMain(), BackendRun(),
>> > > WalSende
On Mon, Mar 19, 2012 at 1:01 PM, Alvaro Herrera
wrote:
> I'm rather of the contrary opinion -- surely if we're going to complete
> function names, we should only complete those that are in schemas in the
> path; similarly for column names.
I think it makes sense to only include currently-visible
On Sun, Feb 19, 2012 at 12:10 PM, Pavel Stehule wrote:
> Hello
>
> I found so this extremely simple patch should be useful.
>
> It helps for pattern SELECT fx();
>
> There was thread about it.
Hi Pavel,
I signed up to be reviewer for this patch, and finally got around to
taking a look. This threa
On Mon, Jun 18, 2012 at 3:56 AM, Dean Rasheed wrote:
> On 18 June 2012 04:21, Josh Kupershmidt wrote:
>> As a side note unrelated to this patch, I also dislike how function
>> name tab-completions will not fill in the opening parenthesis, which
>> makes for unnecessary work
[Hope it's OK if I move this thread to -hackers, as part of CF review.]
On Sat, Jun 9, 2012 at 2:40 AM, Dean Rasheed wrote:
> Hi,
>
> I noticed this while testing 9.2, but it seems to go back to at least
> 8.3. Tab completion of function arguments doesn't work if the function
> is schema-qualifie
Hi all,
Bosco Rama recently complained[1] about not seeing a message printed
by pg_restore for each LO to be restored. The culprit seems to be the
different level passed to ahlog() for this status message:
pg_backup_archiver.c: ahlog(AH, 2, "restoring large object with OID %u\n",
oid);
pg_back
On Wed, May 9, 2012 at 8:11 PM, Bruce Momjian wrote:
> I have completed my draft of the 9.2 release notes, and committed it to
> git. I am waiting for our development docs to build, but after 40
> minutes, I am still waiting:
This bit:
Previously supplied years and year masks of less than four
Hi all,
I think psql's \dO command is missing the server version check which
similar commands such as \dx use. Right now \dO errors out with:
test=# \dO
ERROR: relation "pg_catalog.pg_collation" does not exist
when talking to servers older than 9.1, which don't have pg_collation.
Simple patch f
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan wrote:
> On 11 April 2012 15:35, Magnus Hagander wrote:
>> For example, Thom (and others) could collect a number of typo fixes in
>> their own repo and then just ask for a merge.The advantage over just
>> staging multiple commits and then submitti
On Tue, Apr 10, 2012 at 10:38 AM, Peter Eisentraut wrote:
> On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
>> I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
>> try to tab-complete commands like:
>> ALTER ROLE jsmith WIT
Hi all,
I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
try to tab-complete commands like:
ALTER ROLE jsmith WITH [TAB]
COPY tbl FROM 'filename' WITH [TAB]
you'll get 'RECURSIVE' unhelpfully filled in. I think 'RECURSIVE'
should only be suggested if 'WITH' is the first a
On Tue, Mar 20, 2012 at 7:53 AM, Tom Lane wrote:
> I'm not entirely convinced that that was a good idea. However, so far
> as vacuumlo is concerned, the only reason this is a problem is that
> vacuumlo goes out of its way to do all the large-object deletions in a
> single transaction. What's th
I noticed a misleading error message recently while using createdb. Try:
test=# CREATE ROLE dummy NOLOGIN;
Now, attempt to use createdb as that role. Here's 9.1.1:
$ createdb -Udummy testdb
createdb: could not connect to database postgres: FATAL: role "dummy"
is not permitted to log in
And her
On Wed, Feb 1, 2012 at 1:13 PM, Peter Eisentraut wrote:
> On sön, 2012-01-15 at 18:14 -0500, Josh Kupershmidt wrote:
>> I see this patch includes a small change to dropuser, to make the
>> 'username' argument mandatory if --interactive is not set, for
>> symmetry
On Tue, Jan 31, 2012 at 10:29 AM, Gabriele Bartolini
wrote:
> Here is my final version which embeds comments from Josh. I have also added
> debug information to be printed in case '-d' is given.
Looks fine; will mark Ready For Committer.
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Fri, Jan 27, 2012 at 9:47 AM, Robert Haas wrote:
> On Sun, Jan 15, 2012 at 5:05 PM, Josh Kupershmidt wrote:
>> On Sun, Jan 15, 2012 at 3:02 PM, Gabriele Bartolini
>> wrote:
>>
>>> My actual intention was to have the filename as output of the command, in
&g
On Mon, Jan 23, 2012 at 5:28 PM, Dominik Bylica wrote:
> Hello.
>
> It's probably not the right place to write, but I guess you are there to
> take care of it.
>
> When I was creating a trigger with command like:
> create trigger asdf before update on beginninOfTheNameOfMyTable...
> I hit tab and
On Thu, Dec 22, 2011 at 2:26 PM, Peter Eisentraut wrote:
> On lör, 2011-11-26 at 01:28 +0200, Peter Eisentraut wrote:
>> I propose that we change createuser so that it does not prompt for
>> anything by default. We can arrange options so that you can get prompts
>> for whatever is missing, but by
On Sun, Jan 15, 2012 at 3:02 PM, Gabriele Bartolini
wrote:
> My actual intention was to have the filename as output of the command, in
> order to easily "pipe" it to another script. Hence my first choice was to
> use the stdout channel, considering also that pg_archivecleanup in dry-run
> mode is
On Sun, Dec 11, 2011 at 9:52 AM, Gabriele Bartolini
wrote:
> Hi guys,
>
> I have added the '-n' option to pg_archivecleanup which performs a dry-run
> and outputs the names of the files to be removed to stdout (making possible
> to pass the list via pipe to another process).
>
> Please find atta
On Tue, Dec 13, 2011 at 5:59 AM, Greg Smith wrote:
> Same-user cancels, but not termination. Only this, and nothing more.
+1 from me on this approach. I think enough people have clamored for
this simple approach which solves the common-case.
> There's one obvious and questionable design decisio
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan wrote:
>> Also, should the malloc() of newval just use pg_malloc() instead?
>
> Yes, also done.
This bit is unnecessary, since pg_malloc() takes care of the error handling:
+ if (!newval)
+ {
+
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan wrote:
> Updated patch is attached - adding to Nov commitfest.
Review of the v2 patch:
* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters being used in psql-ref.sgml where they shouldn't
be.
On Mon, Nov 14, 2011 at 7:04 PM, Josh Kupershmidt wrote:
> But it reminded me of another issue. With OS X 10.6.8, and otool -L
> reporting that psql depends on libedit version 2.11.0, the up-arrow
> recall of Tomas' query gets truncated around here:
> 5I0/NTm+fFkB0McY9E2fAA
Hi all,
Commit c7f23494c1103f87bcf1ef7cbfcd626e73edb337 editorialized a bit on
Gurjeet Singh's patch to implement \ir for psql, particularly in
process_file(). Unfortunately, it looks like it broke the common case
of loading a .SQL file in psql's working directory. Consider the
following test case
On Mon, Nov 14, 2011 at 1:01 PM, Robert Haas wrote:
> It looks like the problem is that the original has a blank line after
> the line that says "Version: GnuPG v2.0.17 (GNU/Linux)", but when you
> recall it from the query buffer, that extra blank line gets elided.
>
> The attached patch fixes it
On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom wrote:
> Concise output might look like (bikeshed argument: "splat" indicates
> columns "squashed" out):
>
> test=# \d+ foo
> Table "public.foo"
> Column | Type # Storage #
> +-+-+
> a | in
Someone (me) didn't get the version check for part of psql's \dd
command quite right. I was using a 9.2 client on a 9.1 server and got
this when I ran \dd:
ERROR: function pg_catalog.pg_opfamily_is_visible(oid) does not exist
LINE 33: AND pg_catalog.pg_opfamily_is_visible(opf.oid)
since pg_opf
On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane wrote:
>> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when
>> talking to a 7.3 server. It's not a big deal, but it'd be nice if we
>> could instead error out with a "sorry, we're too lazy to try to
>> support 7.3" on the meta-commands
On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
> Have you tried \d+ with this psql mode:
>
> \pset format wrapped
>
> It wraps the data so it fits on the screen --- it is my default in my
> .psqlrc.
I think that's one of the many psql features I haven't experimented
with, thanks for
[Sorry for not CC'ing the list before, I'm still getting used to the
new Gmail interface]
On Tue, Nov 8, 2011 at 11:05 PM, Josh Kupershmidt wrote:
> On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>>> We're essentially pretending th
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas wrote:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
Seriously, parts of psql are starting to become a real mess.
[tangenti
On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas wrote:
> I don't strongly object to this, but I wonder how useful it will
> really be in practice. It strikes me as the sort of advanced psql
> hackery that only a few people will use, and only some of those will
> gain any benefit.
I'm probably just
On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes wrote:
>> test=# \d+ foo
>> Table "public.foo"
>> Column | Type | Storage
>> +-+-
>> a | integer | plain
>> b | integer | plain
>> Has OIDs: no
>
> Using your example, what if column '
Hi all,
The good news is that psql's backslash commands are becoming quite
thorough at displaying all information which could conceivably be of
interest about an object. The bad news is, psql's backslash commands
often produce a lot of noise and wasted output. (There was some
grumbling along these
On Fri, Nov 4, 2011 at 10:05 AM, Magnus Hagander wrote:
> On Fri, Nov 4, 2011 at 14:53, Cédric Villemain
>> Interesting, can the ouput be clear on the value being a default or an
>> explicit stat target ? (not mandatory but I believe I would like to
>> have it only when the stat target is jnot the
On Thu, Oct 20, 2011 at 5:16 PM, Andreas Karlsson wrote:
> A new version is attached.
Looks fine. Marking ready for committer (CF 2011-11).
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane wrote:
> Josh Kupershmidt writes:
>> Incidentally, I was wondering what the heck was up with a clause like this:
>> else if (pg_strcasecmp(prev_wd, "EXECUTE") == 0 &&
>> pg_strcasecmp(prev2_wd,
On Mon, Sep 26, 2011 at 5:03 PM, Andreas Karlsson wrote:
> Magnus's patch for adding tab completion of views to the TABLE statement
> reminded me of a minor annoyance of mine -- that EXECUTE always completes
> with "PROCEDURE" as if it would have been part of CREATE TRIGGER ... EXECUTE
> even when
On Wed, Oct 12, 2011 at 2:49 PM, Robert Haas wrote:
> So, I think the critical question for this patch is "do we want
> this?".
Yep. Or put another way, are the gains worth having another system
view we'll have to maintain forever?
> Tom didn't like it,
In [1], Tom seemed to be mainly angling f
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan wrote:
> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
>> [need way to show current values]
> \! echo $foo
>
> (which is how I tested the patch, of course)
Ah, right. IMO it'd be helpful to mention that echo exa
1 - 100 of 175 matches
Mail list logo
