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

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

Re: [HACKERS] pg_restore multiple --function options

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

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

Re: [HACKERS] Psql names completion.

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

Re: [HACKERS] Dry-run mode for pg_archivecleanup

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

Re: [HACKERS] Dry-run mode for pg_archivecleanup

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

Re: [HACKERS] disable prompting by default in createuser

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

[HACKERS] misleading error message from connectMaintenanceDatabase()

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

Re: [HACKERS] vacuumlo issue

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

[HACKERS] psql: tab completions for 'WITH'

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

Re: [HACKERS] psql: tab completions for 'WITH'

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

Re: [HACKERS] Last gasp

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

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

[HACKERS] isolationtester and 'specs' subdirectory

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

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

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

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

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

Re: [HACKERS] fixing pg_ctl with relative paths

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

Re: [HACKERS] fixing pg_ctl with relative paths

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

Re: [HACKERS] fixing pg_ctl with relative paths

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

Re: [HACKERS] vacuumlo - use a cursor

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

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

[HACKERS] tab-completion for \lo_import

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:

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

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

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

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 >

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

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

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

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

[HACKERS] allowing multiple PQclear() calls

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

Re: [HACKERS] allowing multiple PQclear() calls

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: >>>> >>&

Re: [HACKERS] Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)

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

Re: [HACKERS] Multiple --table options for other commands

; 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: >>

Re: [HACKERS] Multiple --table options for other commands

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

Re: [HACKERS] Multiple --table options for other commands

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

Re: [HACKERS] Multiple --table options for other commands

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:

Re: [HACKERS] Multiple --table options for other commands

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

Re: [HACKERS] Patch for checking file parameters to psql before password prompt

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

[HACKERS] discarding duplicate indexes

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

Re: [HACKERS] discarding duplicate indexes

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

[HACKERS] bad examples in pg_dump README

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

Re: [HACKERS] bad examples in pg_dump README

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

Re: [HACKERS] bad examples in pg_dump README

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

Re: [HACKERS] string escaping in tutorial/syscat.source

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'

[HACKERS] fixing pg_ctl with relative paths

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

Re: [HACKERS] Tab completion for view triggers in psql

On Tue, Nov 23, 2010 at 10:21 PM, David Fetter wrote: > Please find attached a patch changing both this and "updateable" to > "updatable," also per the very handy git grep I just learned about :) I looked a little more at this patch today. I didn't find any serious problems, though it would have

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Fri, Nov 26, 2010 at 7:11 PM, Robert Haas wrote: > I'm not totally convinced that this is the correct behavior.  It seems > a bit surprising that UPDATE privilege on a single column is enough to > lock out all SELECT activity from the table.  It's actually a bit > surprising that even full-tabl

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Nov 29, 2010 at 10:50 AM, Robert Haas wrote: > A user with single-column UPDATE privileges could obtain a ROW > EXCLUSIVE lock by issuing an UPDATE statement, but currently cannot > obtain the same lock using LOCK TABLE.  It would be reasonable and > consistent to allow such a user to take

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas wrote: > On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote: >> I actually hadn't thought of that, for some reason. >> >> We used to similarly recommend that people handle TRUNCATE privileges >> with a securit

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera wrote: > It occurs to me that we may need a new mode, which disconnects sessions > that are not in a transaction (or as soon as they are) but leaves > in-progress transactions alone; this could be the new default.  Of > course, this is much more dif

Re: [HACKERS] psql: Add \dL to show languages

On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson wrote: > Hi Josh, > > Here is my review of this patch for the commitfest. > > Review of https://commitfest.postgresql.org/action/patch_view?id=439 Thanks a lot for the review! > Contents and Purpose > > > This patch adds the

Re: [HACKERS] psql: Add \dL to show languages

On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote: > On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote: >>> I do not like the use of parentheses in the usage description "list >>> (procedural) languages". Why not have it simply as "list procedural >>> languages"? >> >> Because it lists non-

Re: [HACKERS] psql: Add \dL to show languages

ando's original patch, and I just didn't bother to take it out. If others feel the same way, I'd be happy to rip those columns out. Few more comments below: On Mon, Jan 17, 2011 at 3:51 PM, Andreas Karlsson wrote: > On Sun, 2011-01-16 at 22:32 -0500, Josh Kupershmidt wrote: &g

Re: [HACKERS] psql: Add \dL to show languages

On Tue, Jan 18, 2011 at 1:35 PM, Andreas Karlsson wrote: > Hi Josh, > > Nope, I do not have any better ideas than "DO Blocks?". > > Everything looks good with the exception one bug now. > > \dL foo > * QUERY ** > SELECT l.lanname AS "Name", >       pg_catalog.pg_get_userbyid(l.lano

Re: [HACKERS] psql: Add \dL to show languages

On Wed, Jan 19, 2011 at 9:09 PM, Robert Haas wrote: > This patch doesn't seem terribly consistent to me - we show the name > of the call handler and the name of the validator, but for the inline > handler we just indicate whether there is one or not.  That seems like > something that we should mak

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

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

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

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

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

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

Re: [HACKERS] bugfix: --echo-hidden is not supported by \sf statements

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

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

[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

[HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

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&#

Re: [HACKERS] Add some regression tests for SEQUENCE

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

Re: [HACKERS] Ignore invalid indexes in pg_dump

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

Re: [HACKERS] pg_dump/restore syntax checking bug?

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

Re: [HACKERS] pg_reorg in core?

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

Re: [HACKERS] pg_reorg in core?

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 >

[HACKERS] string escaping in tutorial/syscat.source

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

[HACKERS] Multiple --table options for other commands

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

Re: [HACKERS] Multiple --table options for other commands

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

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Tue, Feb 9, 2010 at 5:49 AM, Leonardo F wrote: > Not even a comment? As I said, performance results on my system > were very good > Hi Leonardo, Perhaps you could supply a .sql file containing a testcase illustrating the performance benefits you tested with your patch -- as I understand,

[HACKERS] patch: Distinguish between unique indexes and unique constraints

Addressing TODO item "Distinguish between unique indexes and unique constraints in \d+" for psql, and picking up from thread: http://archives.postgresql.org/message-id/8780.1271187...@sss.pgh.pa.us Attached is a simple patch which clarifies unique constraints with "UNIQUE CONSTRAINT" in psql's \d+

Re: [HACKERS] patch: Distinguish between unique indexes and unique constraints

On Sun, Apr 18, 2010 at 11:41 AM, Robert Haas wrote: > Josh - you may want to add your patch here: > > https://commitfest.postgresql.org/action/commitfest_view/open Added, thanks! Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

[HACKERS] psql: server version check for \dO

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

Re: [HACKERS] Draft release notes complete

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

[HACKERS] pg_restore logging inconsistency

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

Re: [HACKERS] [BUGS] Tab completion of function arguments not working in all cases

[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

Re: [HACKERS] [BUGS] Tab completion of function arguments not working in all cases

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

Re: [HACKERS] patch: autocomplete for functions

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

Re: [HACKERS] patch: autocomplete for functions

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

Re: [HACKERS] return values of backend sub-main functions

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

[HACKERS] pg_signal_backend() asymmetry

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

Re: [HACKERS] pg_signal_backend() asymmetry

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_

Re: [HACKERS] Posix Shared Mem patch

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,

Re: [HACKERS] autocomplete - SELECT fx

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

Re: [HACKERS] autocomplete - SELECT fx

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

Re: [HACKERS] [PATCH] psql \n shortcut for set search_path =

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)

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Mon, Sep 27, 2010 at 10:05 PM, Itagaki Takahiro wrote: > I re-ordered some description in the doc. Does it look better? > Comments and suggestions welcome. I thought this paragraph was a little confusing: ! In the second case, a full table scan is followed by a sort operation. ! The m

Re: [HACKERS] ask for review of MERGE

On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith wrote: > The rest of the compiler warnings I saw didn't look related to his code, > maybe stuff my picky Ubuntu compiler is noticing that was done recently to > HEAD. I haven't checked HEAD without this patch yet to confirm, and am done > for the night

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Wed, Sep 29, 2010 at 11:55 AM, Leonardo Francalanci wrote: > Can someone else test the patch to see if what I found is still valid? > I don't think it makes much sense if I'm the only one that says > "this is faster" :) I ran a few more performance tests on this patch. Here's what I got for th

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Fri, Oct 1, 2010 at 4:33 AM, Leonardo Francalanci wrote: >> I ran a few more performance tests on this patch. Here's what  I got >> for the tests Leonardo posted originally: >>    * 2M  rows:  22 seconds for seq. scan, 24 seconds for index scan >>    * 5M  rows:  139 seconds for seq. scan, 97 s

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Mon, Oct 4, 2010 at 8:42 AM, Robert Haas wrote: > Did you also adjust random_page_cost? No, my seq_page_cost (1) and random_page_cost (4) are from the defaults. Here are all my non-default settings: test=# SELECT name, unit, setting FROM pg_settings WHERE source != 'default'; nam

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Mon, Oct 4, 2010 at 4:47 PM, Leonardo Francalanci wrote: >> It sounds like the costing model might need a bit more work before  we commit >>this. > > > I tried again the simple sql tests I posted a while ago, and I still get the > same ratios. > I've tested the applied patch on a dual opteron +

Re: [HACKERS] [GENERAL] column-level update privs + lock table

[Moving to -hackers] On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs wrote: > On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: >> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt wrote: >> >> > I noticed that granting a user column-level update privileges doesn&#

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas wrote: > Please add this to > https://commitfest.postgresql.org/action/commitfest_view/open > > I want to look at this at some point, but we still have over a dozen > patches from the current CF to deal with. Added at

[HACKERS] psql autocompletion for \z and \dg

Hi all, It looks like psql's tab completion for the \z and \dg commands in psql are missing. I couldn't see a reason for this, so attached patch fixes. Also, this patch proposes to change psql's "\?" help text to say that \dg and \du are the same, since AFAICT they do exactly the same thing. Jos

Re: [HACKERS] psql autocompletion for \z and \dg

On Thu, Oct 21, 2010 at 8:45 PM, Robert Haas wrote: > Please add this in the usual spot: > https://commitfest.postgresql.org/action/commitfest_view/open Aye sir, added. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

[HACKERS] psql: Add \dL to show languages

Hi all, I'd like to revive Fernando Ike's patch implementing the "\dL" command for psql to list available languages, last version here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php The original patch produced columns "Name", "Owner", "Procedural Language", "Trusted", "Call

Re: [HACKERS] psql: Add \dL to show languages

On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas wrote: > Please add this patch to the currently open CommitFest: Added to 2011-01. > https://commitfest.postgresql.org/action/commitfest_view/open > > And please also help with review of patches from the current CommitFest: > > https://commitfest.post

Re: [HACKERS] Tab completion for view triggers in psql

On Fri, Oct 29, 2010 at 10:33 AM, David Fetter wrote: > That seems like a matter for a separate patch.  Looking this over, I > found I'd created a query that can never get used, so please find > enclosed the next version of the patch :) I like "deletables" better than "deleteables" for Query_for_

[HACKERS] Review: psql include file using relative path

I had a chance to give this patch a look. This review is of the second patch posted by Gurjeet, at: http://archives.postgresql.org/message-id/AANLkTi=yjb_a+ggt_pxmrqhbhyid6aswwb8h-lw-k...@mail.gmail.com == Summary == This patch implements the \ir command for psql, with a long alias \include_relati

  1   2   >