Re: [HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

> On Nov 1, 2017, at 1:02 PM, Nico Williams wrote: > > On Thu, Mar 19, 2015 at 05:41:02PM -0500, David Christensen wrote: >> The two-arg form of the current_setting() function will allow a >> fallback value to be returned instead of throwing an error when an >> unk

[HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

The two-arg form of the current_setting() function will allow a fallback value to be returned instead of throwing an error when an unknown GUC is provided. This would come in most useful when using custom GUCs; e.g.: -- errors out if the 'foo.bar' setting is unset SELECT current_setting('foo.

[HACKERS] [PATCH] Add two-arg for of current_setting(NAME, FALLBACK)

The two-arg form of the current_setting() function will allow a fallback value to be returned instead of throwing an error when an unknown GUC is provided. This would come in most useful when using custom GUCs; e.g.: -- errors out if the 'foo.bar' setting is unset SELECT current_setting('foo.

[HACKERS] [PATCH] Remove defunct and unnecessary link

The HA docs reference a “glossary” link which is no longer accessible, nor is it likely to be useful in general to link off-site IMHO. This simple patch removes this link. Best, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 0001-Remove-defunct-and

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

> On Mar 9, 2017, at 1:01 PM, Robert Haas wrote: > > On Sun, Feb 19, 2017 at 12:02 PM, David Christensen > wrote: >> Hi Robert, this is part of a larger patch which *does* enable the checksums >> online; I’ve been extracting the necessary pieces out with the und

[HACKERS] Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

> Hi David, > > Here's a review of your patch. Hi Ilmari, thanks for your time and review. I’m fine with the revised version. Best, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

> On Feb 19, 2017, at 8:14 PM, Jim Nasby wrote: > > On 2/19/17 11:02 AM, David Christensen wrote: >> My design notes for the patch were submitted to the list with little >> comment; see: >> https://www.postgresql.org/message-id/1E6E64E9-634B-43F4-8AA2-CD85AD92D2F8%4

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

> On Feb 19, 2017, at 5:05 AM, Robert Haas wrote: > > On Fri, Feb 17, 2017 at 2:28 AM, David Christensen wrote: >> - Change "data_checksums" from a simple boolean to "data_checksum_state", an >> enum type for all of >> the potentially-requir

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

On Feb 17, 2017, at 10:31 AM, Magnus Hagander wrote: > > On Thu, Feb 16, 2017 at 9:58 PM, David Christensen wrote: > Extracted from a larger patch, this patch provides the basic infrastructure > for turning data > checksums off in a cluster. This also sets up the neces

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

ablocks without > checksum starts replicating. Good point; I’ll send a revision soon. -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

[HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

in the cluster. I have *not* changed the default in initdb to enable checksums, but this would be trivial. disable-checksums.patch Description: Binary data -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hacker

[HACKERS] [PATCH] Fix pg_proc comment grammar

Fixes some DESCR() grammar mistakes introduced by the xlog -> wal changes. --- src/include/catalog/pg_proc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h index 41c12af..bb7053a 100644 --- a/src/include/catalo

[HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

Throws a build error if we encounter a different number of fields in a DATA() line than we expect for the catalog in question. Previously, it was possible to silently ignore any mismatches at build time which could result in symbol undefined errors at link time. Now we stop and identify the infri

Re: [HACKERS] Online enabling of page level checksums

> On Jan 23, 2017, at 10:59 AM, David Christensen wrote: > >> >> On Jan 23, 2017, at 10:53 AM, Simon Riggs wrote: >> >> On 23 January 2017 at 16:32, David Christensen wrote: >> >>> ** Handling checksums on a standby: >>> >>&g

Re: [HACKERS] Online enabling of page level checksums

> On Jan 23, 2017, at 10:53 AM, Simon Riggs wrote: > > On 23 January 2017 at 16:32, David Christensen wrote: > >> ** Handling checksums on a standby: >> >> How to handle checksums on a standby is a bit trickier since checksums are >> inherently a local

Re: [HACKERS] Online enabling of page level checksums

of the pg_class/pg_database catalog records are replay, we'll be guaranteed to have the checksums calculated on the standby by the time it appears valid due to system state. We may also be able to use the WAL records to speed up the processing of existing heap files if they are interrupted for some reason, this remains to be seen. ** Testing changes: We need to add separate initdb checksum regression test which are outside of the normal pg_regress framework. -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Add EXPLAIN (ALL) shorthand

default >> to ON just like COSTS and TIMING do. Yeah, that would be an incompatible >> change, but that's what major releases are for no? > > After thinking about it, i think this is a better idea. Yeah, if that’s the only practical difference, WORKSFORME; I can see the poin

Re: [HACKERS] [PATCH] Add EXPLAIN (ALL) shorthand

> On May 19, 2016, at 3:17 PM, Евгений Шишкин wrote: > > >> On 19 May 2016, at 22:59, Tom Lane wrote: >> >> David Christensen writes: >>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN >>> (ANALYZE, VERBOSE, COSTS

[HACKERS] [PATCH] Add EXPLAIN (ALL) shorthand

This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability. 0001-Add-EXPLAIN-ALL-shorthand.patch Description: Binary data -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

> On Oct 9, 2015, at 2:17 PM, Robert Haas wrote: > > On Thu, Oct 8, 2015 at 12:43 PM, David Christensen wrote: >> I’m happy to move it around, but If everything is in order, how will this >> affect things at all? If we’re in a good state this condition should never &

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

> On Oct 8, 2015, at 11:23 AM, Robert Haas wrote: > > On Tue, Oct 6, 2015 at 9:15 AM, David Christensen wrote: >> Fixes a build issue I ran into while adding some columns to system tables: >> >>Throws a build error if we encounter a different number of fields

[HACKERS] [PATCH] Comment fixes

Use the correct name “pgindent” in comments. 0001-Make-pgindent-references-consistent.patch Description: Binary data -- David Christensen PostgreSQL Team Manager End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

time which could result in symbol undefined errors at link time. Now we stop and identify the infringing line as soon as we encounter it, which greatly speeds up the debugging process. 0001-Teach-Catalog.pm-how-many-attributes-there-should-be.patch Description: Binary data -- David

Re: [HACKERS] [DESIGN] Incremental checksums

revalidating” since your database is still actively making changes, you need to validate writes too (think new tables, etc). “Enabling” needs reads unvalidated because you’re starting from an unknown state (i.e., not checksummed already). Thanks, David -- David Christensen PostgreSQL Team Manag

[HACKERS] [PATCH] Comment fix for miscinit.c

Quick comment fix for edit issue. 0001-Fix-comment.patch Description: Binary data -- David Christensen PostgreSQL Team Manager End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [DESIGN] Incremental checksums

Some people may decide that checksums end up taking too much overhead or similar, we should support disabling of this feature; with this proposed patch the disable action is fairly trivial to handle. Requesting an explicit checksum cycle would be desirable in the case where you want to pro

Re: [HACKERS] [DESIGN] Incremental checksums

> On Jul 13, 2015, at 3:50 PM, Jim Nasby wrote: > > On 7/13/15 3:26 PM, David Christensen wrote: >> * Incremental Checksums >> >> PostgreSQL users should have a way up upgrading their cluster to use data >> checksums without having to do a costly

[HACKERS] [DESIGN] Incremental checksums

r support) [0/7] - [ ] pg_control updates for new data_checksum_cycle, data_checksum_state - [ ] pg_class changes - [ ] pg_database changes - [ ] function API - [ ] autovac launcher modifications - [ ] checksum bgworker - [ ] doc updates - Milestone 2 (pg_upgrade support) [0/4]

[HACKERS] [PATCH] correct the initdb.log path for pg_regress

When encountering an initdb failure in pg_regress, we were displaying the incorrect path to the log file; this commit fixes all 3 places this could occur. 0001-Output-the-correct-path-for-initdb.log-in-pg_regress.patch Description: Binary data -- David Christensen PostgreSQL Team Manager

Re: [HACKERS] [PATCH] Add missing \ddp psql command

> On Jul 7, 2015, at 3:53 AM, Fujii Masao wrote: > > On Tue, Jul 7, 2015 at 2:11 AM, David Christensen wrote: >> Quickie patch for spotted missing psql \ddp tab-completion. > > Thanks for the report and patch! > > I found that tab-completion was not supported

Re: [HACKERS] Add checksums without --initdb

e new tool: - pg_enablechecksums -- basic tool to set the data_checksum_state flag of pg_control Other thoughts Do we need periodic CRC scanning background worker just to check buffers periodically? - if so, does this cause any interference with frozen relations? What additional changes would be req

[HACKERS] [PATCH] Add missing \ddp psql command

Quickie patch for spotted missing psql \ddp tab-completion. 0001-Add-missing-ddp-psql-tab-completion.patch Description: Binary data -- David Christensen PostgreSQL Team Manager End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Add checksums without --initdb

case for, but I also think there’s some benefit to be found in having it happen while the replica is being streamed/built. Ideas/thoughts/reasons this wouldn’t work? David -- David Christensen PostgreSQL Team Manager End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

; > Since code changes were good, just fixed reported cosmetic changes. > > David, can you please cross check? Hi Jeevan, I’m just on the digest list, and it looks like I didn’t get copied on your response, so missed it until now. Thanks for the review; I reviewed the changes you made an

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

> On Mar 20, 2015, at 11:10 AM, David G. Johnston > wrote: > > On Fri, Mar 20, 2015 at 9:04 AM, Robert Haas wrote: > On Fri, Mar 20, 2015 at 10:54 AM, David Christensen > wrote: > > In that case, the other thought I had here is that we change the function > >

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

> On Mar 19, 2015, at 6:27 PM, Tom Lane wrote: > > David Christensen writes: >> The two-arg form of the current_setting() function will allow a >> fallback value to be returned instead of throwing an error when an >> unknown GUC is provided. This would come in most

[HACKERS] [PATCH] two-arg current_setting() with fallback

#x27;) This would save you having to wrap the use of the function in an exception block just to catch and utilize a default setting value within a function. 0001-Add-two-arg-for-of-current_setting-NAME-FALLBACK.patch Description: Binary data -- David Christensen End Point Corporation da..

[HACKERS] Simple documentation typo patch

h-for-typo-in-built-in-conversion-type-names.patch Description: Binary data Regards, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Deriving release notes from git commit messages

ecause it's tough to guarantee that *all* this data > would be correctly captured at commit time, and you can't revise it > after the commit gets pushed upstream. Perhaps `git notes` could be something used to annotate these: http://www.kernel.org/pub/software/scm/git/docs/git-note

Re: [HACKERS] WIP pgindent replacement

h wouldn't be run against, no? Am I missing something?) Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] LOCK DATABASE

gt;> one used by Slony. > > Yeah, I mentioned this but I think it actually sucks. How would this differ from just UPDATE pg_database SET datallowconn = FALSE for the databases in question? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent

Re: [HACKERS] branching for 9.2devel

y complex that it couldn't be modeled sufficiently easily by a smart enough perl script? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] "stored procedures"

, could that be done in such a way that it would take precedence over a parallel backend attempting to acquire the same locks without blocking the procedure? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add missing keywords to gram.y's unreserved_keywords list.

; >> ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as >> valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the >> constraint is valid. > > Yeah, it's a little awkward, but I think it's still better than adding >

Re: [HACKERS] multiple -f support

ted as a file to process; i.e.,: $ psql -U user [option] database -- file1.sql file2.sql file3.sql This would allow things like shell expansion to work as expected: $ ls 01-schema.sql02-data1.sql03-fixups.sql $ psql database -- *.sql etc. Regards, David -- David Christensen End Poin

Re: [HACKERS] Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum

orrectly set, causing rows to appear visible in seqscans when they should not be. This might explain recent reports of data corruption from Jeff Ross and others. In passing, do a bit of editorialization on comments in visibilitymap.c. oy:postgresql machack$ git describe

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

; to keep the barrier to creating PostgreSQL extensions as low as is reasonably > possible. I assume this has already been discussed and rejected (or it wouldn't still be an issue), but what's wrong with the equivalent of \i in the successive .sql upgrade files? Or is the server ru

Re: [HACKERS] plperlu problem with utf8

e > bytea input or output we try to encode that the same as any string. I > think thats going to be a bit more invasive and this patch should > stands on its own. > Yeah, I'm not sure how invasive that will end up being, or if there are other datatypes which should skip the text proces

Re: [HACKERS] plperlu problem with utf8

decode from an octets-only encoding, it's your responsibility to do so after you've unescaped it. Perhaps later versions of the URI::Escape module contain a uri_unescape_utf8() function, but it's trivially: sub uri_unescape_utf8 { Encode::decode_utf8(uri_unescape(shift))}. This is definitely not a bug in uri_escape, as it is only defined to return octets. >>> * Values returned from PL/Perl functions that are in Perl's internal >>> representation should be encoded into the server encoding before they're >>> returned. >>> I didn't really follow all of the above; are you aiming for the same thing? >> >> Yeah, the patch address this part. Right now we just spit out >> whatever the internal format happens to be. > > Ah, excellent. I agree with the sentiments that: data (server_encoding) -> function parameters (-> perl internal) -> function return (-> server_encoding). This should be for any character-type data insofar as it is feasible, but ISTR there is already datatype-specific marshaling occurring. >> Anyway its all probably clear as mud, this part of perl is one of the >> hardest IMO. > > No question. There is definitely a lot of confusion surrounding perl's handling of character data; I hope this was able to clear a few things up. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

> > Perhaps a more useful definition would be > > EXCHANGE TABLE target WITH source; > > which just swaps the heap and indexes of each table. > You can then use TRUNCATE if you want to actually destroy data. Are there any considerations with toast tables and the in

Re: [HACKERS] SQL command to edit postgresql.conf, with comments

T PERMANENT couldn't be used on a read-only standby? Could this be to manage some of the failover scenarios (i.e., setting any relevant config from a central clusterware|whatever)? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql

Re: [HACKERS] Which file does the SELECT?

g and help answer some of these questions. `git grep` will also come in handy if you're working directly from a git checkout. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] standby registration (was: is sync rep stalled?)

f multiple per data center, or even just utilize role sizes of 1 if you wanted individual standbys to be "named" in this fashion. This role could be provided on connect of the standby is more-or-less tangential to the specific registration issue. Regards, David -- David Christensen

Re: [HACKERS] [COMMITTERS] pgsql: Still more tweaking of git_changelog.

BLE remotes/origin/REL8_5_ALPHA1_BRANCH remotes/origin/REL8_5_ALPHA2_BRANCH remotes/origin/REL8_5_ALPHA3_BRANCH remotes/origin/REL9_0_ALPHA4_BRANCH remotes/origin/REL9_0_ALPHA5_BRANCH remotes/origin/REL9_0_STABLE remotes/origin/master Regards, David -- David Christensen End

Re: [HACKERS] Multi-branch committing in git, revisited

rship/commit time for the commit in question. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Triggers on VIEWs

umably the other related instances of "before" and "after") were set apart with or similar. This is already in use in some places in this patch, so seems like the correct markup. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pg

[HACKERS] permissions bug in RI checks?

n proposed, but I wanted to understand the reason behind the restrictions if it was intentional behavior. Thanks, David Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] git: uh-oh

things wrong :D, I think we have no choice but aborting the > conversion for now and come back to it later. Can you post the cvs2svn command line used for conversion? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] Patch for 9.1: initdb -C option

he same ground. Like I said in the original submission, I found it helpful for the programmatic configuration of a number of simultaneous node, but if it's not generally useful to the community at large, I'll understand if it's punted. Regards, David -- David Christensen End P

Re: [HACKERS] Explicit psqlrc

nambiguous with the current convention of having an unspecified argument be interpreted as a database name. This would make it possible to actually specify/use multiple files in a fashion that people are used to doing, as opposed to having to explicitly type things out or do contortions will sh

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

lhost -c"\c - - /tmp -" > You are now connected to database "postgres" via local socket on "/tmp". If we print the local socket when it's been explicitly set via the host= param, why not display the actual socket path in the general local socket case? Also, while we're still tweaking this patch, I've had a couple requests for the SSL status of the connection as well; does this seem like a generally useful parameter to display as well? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] documentation for committing with git

ased off the pattern of the committer having > two repositories - one for his own work, one for comitting, much like > I assume all of us have today in cvs. You can also do a rebase after the merge to remove the local merge commit before pushing. I tend to do this anytime I merge a local branch, just to rebase on top of the most recent origin/master. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] documentation for committing with git

doing :-) > > Hmm, I didn't know about that option. What makes us think that's the > behavior people will most often want? Because it doesn't seem like > what I want, just for one example... So you're working on some back branch, and make a WIP commit so you ca

Re: [HACKERS] Explicit psqlrc

h separates out the interactive/non-interactive parts). Kinda yucky, but it's a working solution. 2) have a flag which explicitly includes the psqlrc file in non-interactive use (perhaps if -x is available, use it for the analogue to -X). Regards, David -- David Christensen End Point C

Re: [HACKERS] Patch for 9.1: initdb -C option

touch the default > postgresql.conf file any more, beyond adding one line to the bottom > of it which is an include directive, to bring in our overrides. > > What will make everyone happy here? So you'll now issue: $ initdb ... -C 'include localconfig.conf' ? :-) R

Re: [HACKERS] Explicit psqlrc

m psql -c 'something' -f /dev/null > > I think we should just make sure -X works, and have .psqlrc be read when > it's not specified regardless of -f and -c switches. > > Otherwise it's just plain confusing. +1. Regards, David -- David Christensen End Point Co

Re: [HACKERS] Explicit psqlrc

On Jul 20, 2010, at 9:05 AM, Robert Haas wrote: > On Tue, Jul 20, 2010 at 10:00 AM, David Christensen > wrote: >> Sorry for the delays in response. This is fine; I think there are some >> semantic questions that should still be resolved at this point, particularly >>

Re: [HACKERS] Explicit psqlrc

aths that currently set this up. Are there any gotchas to this approach? (I'm looking essentially for odd code paths where say .psqlrc was not loaded before, but now would be given the proper input of -c, -f file, -f -.) I'll look more in-depth at the posted feedback and Mark's proposed patch. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

On Jul 19, 2010, at 11:10 PM, Robert Haas wrote: > On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas wrote: >> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen >> wrote: >>>> I would propose to print instead: >>>> >>>> You are connected

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

kets, so maybe either the port or the socket path should show up here still. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

On Jul 19, 2010, at 10:34 PM, Robert Haas wrote: > On Sun, Jul 18, 2010 at 2:00 PM, David Christensen wrote: >> Updated the commitfest entry with the patch, updated the title to reflect >> the actual name of the command, and marked as ready for committer. > > I took a loo

[HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

On Jul 18, 2010, at 12:33 PM, David Christensen wrote: > > On Jul 18, 2010, at 12:30 PM, Tom Lane wrote: > >> David Christensen writes: >>> machack:machack:5432=# \c "foo""bar" >>> You are now connected to database "foo"bar&q

Re: [HACKERS] Patch: psql \whoami option

On Jul 18, 2010, at 12:30 PM, Tom Lane wrote: > David Christensen writes: >> machack:machack:5432=# \c "foo""bar" >> You are now connected to database "foo"bar". > > What this is reflecting is that backslash commands have their own

Re: [HACKERS] Patch: psql \whoami option

On Jul 18, 2010, at 12:17 PM, David Christensen wrote: > > On Jun 21, 2010, at 9:00 AM, Tom Lane wrote: > >> Robert Haas writes: >>> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer >>> wrote: >>>> One comment I have on the output format is that va

Re: [HACKERS] Patch: psql \whoami option

ot;foo"bar" unterminated quoted string You are now connected to database "machack". [Sun Jul 18 12:14:59 CDT 2010] machack:machack:5432=# \c "foo""bar" You are now connected to database "foo"bar". As you can see, the value passed to connect d

Re: [HACKERS] SHOW TABLES

read), although that swiped the input before it hit the backend. I don't know if I like the idea of that HINT or not. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC - code of implementation of materialized views

; - ALTER MATERIALIZED VIEW name SET/DROP DEFAULT also doesn't work, >> which is OK: it shouldn't work. But the error message needs work. >> - The error message "CREATE OR REPLACE on materialized view is not >> support!" shouldn't end with an exclamation

Re: [HACKERS] How to pass around collation information

atter, are per-table/column encodings spec, and/or something that we're looking to implement down the line? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] Tags missing from GIT mirror?

uot;9.0devel". But when we switch to beta, we don't have > a devel tree anymore, it's just beta and backbranches. Is there anything to do about the missing tags in git? I've wished for those to be available as well. Regards, David -- David Christensen End Point Corporat

[HACKERS] Patch for 9.1: initdb -C option

stent with postmaster's parsing. The -C flag was chosen to be a mnemonic for "config". Regards, David -- David Christensen End Point Corporation da...@endpoint.com 0001-Add-C-option-to-initdb-to-allow-invocation-time-GUC-.patch Description: Binary data initdb-d

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

this conflict conceptually with the item from "Exotic Features" on the same page?: * Add pre-parsing phase that converts non-ISO syntax to supported syntax This could allow SQL written for other databases to run without modification. Regards, David -- David Christensen End Point C

Re: [HACKERS] Explicit psqlrc

one of the scripts include explicit BEGIN/COMMIT statements (although it is no different than the existing code in this regard). Regards, David -- David Christensen End Point Corporation da...@endpoint.com psql_process_multiple_files.patch Description: Binary data -- Sent via p

Re: [HACKERS] Explicit psqlrc

tions to this (obviously including documentation - this is just the trivial code) My bikeshed has a --psqlrc path/to/file, but +1 on the idea. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

oint? Can failing to stop prevent/delay the shutdown/restart of the server? Etc. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

AGE for those languages with pg_pltemplate entries (specifically plpgsql, but any with the same parameters) and would mean that we could use dumps from pre 9.0 in 9.0 without breaking, appears to fix --single, the pg_regress case, etc. Thoughts on the approach? Regards, David -- David Christe

Re: [HACKERS] Avoiding bad prepared-statement plans.

Hey, it works for git... :-) Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Function to return whole relation path?

On Feb 7, 2010, at 1:30 PM, Tom Lane wrote: David Christensen writes: On Feb 7, 2010, at 11:04 AM, Tom Lane wrote: pg_relation_filepath(regclass) returns text which would expose the output of relpath(), ie, the $PGDATA-relative path name of the relation. Should this return multiple

Re: [HACKERS] Function to return whole relation path?

1002061/68483/172744", "pg_tblspc/ 48372/8.5_201002061/68483/172744.1", etc? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: psql \whoami option

On Jan 27, 2010, at 8:08 AM, Magnus Hagander wrote: 2010/1/27 David Christensen : On Jan 27, 2010, at 4:01 AM, Magnus Hagander wrote: 2010/1/27 Josh Berkus : On 1/26/10 3:24 PM, David Christensen wrote: -hackers, In the spirit of small, but hopefully useful interface improvement

Re: [HACKERS] Patch: psql \whoami option

rrent interfaces. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: psql \whoami option

On Jan 27, 2010, at 4:01 AM, Magnus Hagander wrote: 2010/1/27 Josh Berkus : On 1/26/10 3:24 PM, David Christensen wrote: -hackers, In the spirit of small, but hopefully useful interface improvement patches, enclosed for your review is a patch for providing psql with a \whoami command

[HACKERS] Patch: psql \whoami option

26 17:17:46 CST 2010] machack:postgres:8555=# \whoami dsn dbname=postgres;user=machack;host=localhost;port=8555 [Tue Jan 26 17:19:02 CST 2010] machack:postgres:8555=# \q Regards, David -- David Christensen End Point Corporation da...@endpoint.com diff --git a/doc/src/sgml/ref/psql-ref.sgm

Re: [HACKERS] MySQL-ism help patch for psql

On Jan 21, 2010, at 12:02 PM, Tom Lane wrote: David Christensen writes: Should the error messages between the SHOW cases and the others be consistent ("ERROR: unsupported command" or similar)? It's worth noting that this is only in the psql client, but we could simulate

Re: [HACKERS] Patch: regschema OID type

On Jan 21, 2010, at 11:56 AM, Tom Lane wrote: David Christensen writes: Enclosed is a patch adding a 'regschema' OID type. What in the world is the point of that? The regfoo types are for things that have schema-qualified names. Perhaps the naming is a bit disingenuous, a

Re: [HACKERS] MySQL-ism help patch for psql

On Jan 21, 2010, at 11:48 AM, Florian Weimer wrote: * David Christensen: Currently, a session will look like the following: machack:machack:5485=# show tables; See: \d or \? for general help with psql commands machack:machack:5485=# Said formatting looks like it could

[HACKERS] Patch: regschema OID type

ith the regression tests to add those yet. I hope to address that in a future revision. Thanks, David -- David Christensen End Point Corporation da...@endpoint.com regschema.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Patch rev 2: MySQL-ism help patch for psql

On Jan 19, 2010, at 6:01 PM, David Christensen wrote: On Jan 19, 2010, at 4:23 PM, Robert Haas wrote: On Tue, Jan 19, 2010 at 5:14 PM, David E. Wheeler > wrote: Why would they want more? It's not MySQL, and they know that. If we give them some very minor helpful hints for the mos

[HACKERS] Patch rev 2: MySQL-ism help patch for psql

s needed. Patch enclosed as a context-diff attachment this time. Regards, David -- David Christensen End Point Corporation da...@endpoint.com mysql-help.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

Re: [HACKERS] MySQL-ism help patch for psql

devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] MySQL-ism help patch for psql

On Jan 19, 2010, at 3:39 PM, Tom Lane wrote: David Christensen writes: On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote: well those are the most common ones I guess for the current version of the mysql commandline client - but what about future versions or the fact that we only have

  1   2   >