Re: [HACKERS] gSoC - ADD MERGE COMMAND - code patch submission

On 16/07/10 03:26, Boxuan Zhai wrote: PS: Heikki asked me about what the "EXPLAIN MERGE ..." command will do. Well, I have not test it, but it may through an error or just explain the top plan, since I put the action plans in a new field, which cannot be recognized by old functions. I meant wha

Re: [HACKERS] imessages up-date

Hi, On 07/15/2010 10:37 PM, Alvaro Herrera wrote: > BTW I think this patch series makes sense, though I haven't looked at it > in detail. I guess it means I'll have to have a look at the IMessages > stuff as well. Yes, only after adding these patches to the commit fest, I realized that I'dd have

Re: [HACKERS] (9.1) btree_gist support for searching on "not equals"

Hi, Thank you for the review. On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote: > (1) Exclusion constraints support for operators where "x x" > is false (tiny patch) > https://commitfest.postgresql.org/action/patch_view?id=307 > (2) btree_gist support for searching on <> ("not equals")

Re: [HACKERS] dividing money by money

On tor, 2010-07-15 at 22:25 -0400, Tom Lane wrote: > "Kevin Grittner" writes: > > Andy Balholm wrote: > >> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote: > >> I deleted the excess comments and moved some lines around. Here it > >> is with the changes. > > > I ran pgindent to standardize th

Re: [HACKERS] testing plpython3u on 9.0beta3

> > > You'd have to build the two plpython.so's in separate compile operations. > >regards, tom lane > I hadn't thought of that. Tried it and it does work. Thanks. -- Chris Spotts rfu...@gmail.com

Re: [HACKERS] SHOW TABLES

All, So, from my perspective is that the main issue with the \d commands is that they are not accessible from interfaces other than psql. Often, you have to write a big, hairy, pg-version-specific query to make them happen. information_schema is nice but (a) it's not in the default search path,

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010, Simon Riggs wrote: On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: That seems rather wretched for machine-parsability, which I think is an important property for anything we do in this area. I completely disagree. This is for humans only, and mostly newbies only. A

Re: [HACKERS] suppress automatic recovery after back crash

On Wed, Jul 14, 2010 at 11:59 PM, Robert Haas wrote: > On Wed, Jul 14, 2010 at 3:41 AM, Fujii Masao wrote: >> I read the patch and found some small typos. > > Thanks.  Corrected version attached. > >> We should add something like?: >> >> - >> Even if this value is set to true, a backend c

Re: [HACKERS] dividing money by money

"Kevin Grittner" writes: > Andy Balholm wrote: >> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote: >> I deleted the excess comments and moved some lines around. Here it >> is with the changes. > I ran pgindent to standardize the white space. (No changes of > substance.) Patch attached. >

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 5:34 PM, Simon Riggs wrote: > On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: >> Sounds good, but we need agreement on a more detailed design first. > What do you mean? Exactly which commands are we going to support? With exactly what syntax? What information will

Re: [HACKERS] small exclusion constraints patch

Jeff Davis writes: > Currently, the check for exclusion constraints performs a sanity check > that's slightly too strict -- it assumes that a tuple will conflict with > itself. That is not always the case: the operator might be "<>", in > which case it's perfectly valid for the search for conflict

Re: [HACKERS] SHOW TABLES

Excerpts from David Fetter's message of jue jul 15 19:19:47 -0400 2010: > On Thu, Jul 15, 2010 at 02:31:10PM -0400, Alvaro Herrera wrote: > > Or even > > > > TABLE TABLES; > > > > weird though that is ... > > "Weird though that is," is *exactly* the problem we're trying to > address here. SHOW

Re: [HACKERS] gSoC - ADD MERGE COMMAND - code patch submission

Dear Hackers I considered my situation. And I found that I didn't communicate well with you, as makes you have little confidence on my project. Most of the time I just work by myself and not report to you frequently. I always want to finish a solid stage progress before do a submission. This may b

Re: [HACKERS] [PATCH] elimination of code duplication in DefineOpFamily()

Brent Dombrowski writes: > [ review of KaiGai-san's patch ] Committed. Thanks for the patch, and the review. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] buildfarm housekeeping / planning

Andrew Dunstan writes: > The buildfarm is now going on six years old (time flies when you're > having fun!) and the database is now rather large - around 76Gb on disk. > We'd like to reduce that quite a lot, especially by purging out the logs > of old builds. And while the old data isn't public

[HACKERS] buildfarm housekeeping / planning

The buildfarm is now going on six years old (time flies when you're having fun!) and the database is now rather large - around 76Gb on disk. We'd like to reduce that quite a lot, especially by purging out the logs of old builds. And while the old data isn't publicly accessible, it has occasio

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 02:31:10PM -0400, Alvaro Herrera wrote: > Excerpts from Peter Eisentraut's message of jue jul 15 14:21:26 -0400 2010: > > On tor, 2010-07-15 at 17:35 +0100, Simon Riggs wrote: > > > There should be one command to "display a list of tables" and it needs > > > to be easily gue

[HACKERS] buildfarm owners, please add REL9_0_STABLE to your list of builds

Buildfarm owners: In case you have missed it, the source code tree has been branched somewhat earlier than has happened in previous release cycles, where the branch has occurred any time from just before release to several weeks after. That means that buildfarm owners need to add the new bran

Re: [HACKERS] SHOW TABLES

Le 15 juil. 2010 à 18:43, Magnus Hagander a écrit : > The downside is that you are then limited to what can be returned as a > resultset. A "\d table" in psql returns a hell of a lot more than > that. So do we keep two separate formats for this? Or do we remove the > current, useful, output format

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 15:52 -0400, Andrew Dunstan wrote: > This could presumably be implemented by creating a view to return the > required information and then making "SHOW TABLES" an alias for > "select > * from viewname". > > FYI, MS-SQL does this stuff with some stored procedures. I regularl

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: > That seems rather wretched for machine-parsability, which I think is > an important property for anything we do in this area. I completely disagree. This is for humans only, and mostly newbies only. Anybody that wants structured output can t

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 2:26 PM, Richard Huxton wrote: > 3. Add "SHOW xxx" and have it return a single query > Have it also issue "NOTICE: from psql, try \dt for more info" A big -1 from me on that. Going to a whole lot of trouble to implement something half as functional as what we have already

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: > Sounds good, but we need agreement on a more detailed design first. What do you mean? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 04:20:12PM +0100, Simon Riggs wrote: > > Just for the record, I've never ever met anyone that said "Oh, this \d > syntax makes so much sense. I'm a real convert to Postgres now you've > shown me this". The reaction is always the opposite one; always > negative. Which detrac

Re: [HACKERS] bg worker: overview

Excerpts from Jaime Casanova's message of jue jul 15 15:51:10 -0400 2010: > On Thu, Jul 15, 2010 at 1:28 PM, Markus Wanner wrote: > > > > However, note that the coordinator is designed to be just a message > > passing or routing process, which should not do any kind of time > > consuming processin

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 2:45 PM, Heikki Linnakangas wrote: > On 15/07/10 19:06, Aaron W. Swenson wrote: >> The best solution is to offer a hint to the user in psql when they submit >> 'SHOW . . . .' with a response like: SHOW . . . . is not a valid command. >> Perhaps you mean \d . . . . > > +1. Tha

Re: [HACKERS] SHOW TABLES

On 15/07/10 20:43, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I was assuming the process would be something like: 1. Move existing \d queries into functions* 2. Convert psql to use those Oops! There's goes your ability to handle older versions of Postgres f

Re: [HACKERS] SHOW TABLES

--On 15. Juli 2010 15:52:24 -0400 Andrew Dunstan wrote: FYI, MS-SQL does this stuff with some stored procedures. I regularly use sp_columns to fiind out what I'm really being asked to interact with. See Yeah, something like this was

Re: [HACKERS] bg worker: overview

Hi, On 07/15/2010 09:51 PM, Jaime Casanova wrote: > so, merging this with the autovacuum will drop our hopes of having a > time based autovacuum? not that i'm working on that nor i was thinking > on working on that... just asking to know what the implications are, > and what the future improves co

Re: [HACKERS] SHOW TABLES

Bruce Momjian wrote: I assume SHOW TABLES would only be useful for interactive terminal sesssions, not for application code (which should use information_schema), so what non-psql interactive terminal programs are there? I think your assumption is questionable. Plenty of people use MySQL

Re: [HACKERS] bg worker: overview

On Thu, Jul 15, 2010 at 1:28 PM, Markus Wanner wrote: > > However, note that the coordinator is designed to be just a message > passing or routing process, which should not do any kind of time > consuming processing. It must *coordinate* things (well, jobs) and react > promptly. Nothing else. > s

Re: [HACKERS] Listen/Notify in 9.0

Kaare Rasmussen writes: > As I understand the changes to the notification system in 9.0, apart from > being able to carry a payload, it will guarantee the order of delivery, and > also it will keep the notification and notify any listener, even if the > listener didn't register at the time of n

Re: [HACKERS] SHOW TABLES

On 15/07/10 19:06, Aaron W. Swenson wrote: The best solution is to offer a hint to the user in psql when they submit 'SHOW . . . .' with a response like: SHOW . . . . is not a valid command. Perhaps you mean \d . . . . +1. That doesn't force us to implement a whole new set of commands and synt

Re: [HACKERS] SHOW TABLES

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I was assuming the process would be something like: > 1. Move existing \d queries into functions* > 2. Convert psql to use those Oops! There's goes your ability to handle older versions of Postgres from the existing psql[1]. Cue angry mobs

Re: [HACKERS] SHOW TABLES

Bernd Helmle wrote: > > > --On 15. Juli 2010 18:02:10 +0200 Guillaume Lelarge > wrote: > > > And would you add the complete syntax? I mean: > > > > SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern'] > > > > I'm wondering what one can do with the [FROM db_name] clause :) > > And as soon as y

[HACKERS] Listen/Notify in 9.0

Hi As I understand the changes to the notification system in 9.0, apart from being able to carry a payload, it will guarantee the order of delivery, and also it will keep the notification and notify any listener, even if the listener didn't register at the time of notification. Is this correct?

Re: [HACKERS] ALTER TABLE SET STATISTICS requires AccessExclusiveLock

On 7/7/10 6:04 PM, Cédric Villemain wrote: > I just faced production issue where it is impossible to alter table to > adjust autovacuum settings in a pg8.4. (5K tps, 260M rows table, lock > too much) We could try to resolve the COMMENT ON issue with the same mechanism. What we need is a table lock

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010 22:01:34 +0300 Peter Eisentraut wrote: > On tor, 2010-07-15 at 19:21 +0200, Andreas 'ads' Scherbaum wrote: > > Is there a way to query all databases from information_schema? > > No. This got rejected before, because of "not in the standard". In this case: no way to answer "SH

Re: [HACKERS] SHOW TABLES

On 15/07/10 19:44, Robert Haas wrote: On Jul 15, 2010, at 11:59 AM, Simon Riggs wrote: I imagined that we would do something similar to EXPLAIN, a set of text rows returned. That seems rather wretched for machine-parsability, which I think is an important property for anything we do in this a

Re: [HACKERS] SHOW TABLES

Joshua D. Drake wrote: On Thu, 2010-07-15 at 18:48 +, Greg Sabino Mullane wrote: P.S. What's with the uppercase mania in this thread? Can we please get back to saying "select * from tables" and "show tables"? :) The standard specifies that it it should be uppercase. :P

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 13:16 -0300, Marc G. Fournier wrote: > > Isn't that what the information_schema catalog is for? > > I'd rather write: > > SHOW TABLES; > > then: > > SELECT table_name >FROM information_schema.tables > WHERE table_type = 'BASE TABLE' > AND table_schema NOT IN >

Re: [HACKERS] SHOW TABLES

--On 15. Juli 2010 18:02:10 +0200 Guillaume Lelarge wrote: And would you add the complete syntax? I mean: SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern'] I'm wondering what one can do with the [FROM db_name] clause :) And as soon as you have this, people want to have that list orde

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010, Peter Eisentraut wrote: On tor, 2010-07-15 at 17:35 +0100, Simon Riggs wrote: There should be one command to "display a list of tables" and it needs to be easily guessable for those who have forgotten. Well, if you put information_schema in the default path, it'd be S

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 18:48 +, Greg Sabino Mullane wrote: > P.S. What's with the uppercase mania in this thread? Can we > please get back to saying "select * from tables" > and "show tables"? :) The standard specifies that it it should be uppercase. :P JD -- PostgreSQL.org Major Contr

Re: [HACKERS] SHOW TABLES

On tor, 2010-07-15 at 19:21 +0200, Andreas 'ads' Scherbaum wrote: > Is there a way to query all databases from information_schema? No. -- 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] SHOW TABLES

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Well, if you put information_schema in the default path, it'd be > > SELECT * FROM TABLES; Except it also shows views[1]. Oh, and it has a bunch of other arcane and unwanted columns. Which we can't remove, nor can we add additional columns

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 11:59 AM, Simon Riggs wrote: > On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote: >> On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote: >>> On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: >>> Is there an actual common use-case for having these commands av

Re: [HACKERS] SHOW TABLES

Excerpts from Peter Eisentraut's message of jue jul 15 14:21:26 -0400 2010: > On tor, 2010-07-15 at 17:35 +0100, Simon Riggs wrote: > > There should be one command to "display a list of tables" and it needs > > to be easily guessable for those who have forgotten. > > Well, if you put information_s

Re: [HACKERS] bg worker: overview

Hi, On 07/15/2010 03:45 PM, Dimitri Fontaine wrote: > We've been talking about this topic on -performance: Thank for pointing out this discussion, I'm not following -performance too closely. > So, do you think we could use your work as a base for allowing custom > daemon code? Daemon code? That

Re: [HACKERS] SHOW TABLES

On tor, 2010-07-15 at 17:35 +0100, Simon Riggs wrote: > There should be one command to "display a list of tables" and it needs > to be easily guessable for those who have forgotten. Well, if you put information_schema in the default path, it'd be SELECT * FROM TABLES; -- Sent via pgsql-ha

Re: [HACKERS] cvs to git migration - keywords

* Aidan Van Dyk [100715 13:56]: > * Marko Kreen [100715 13:49]: > > > Eh. I stand corrected - what it actually does is even more > > bizarre - it stores whatever is on the disk, but then > > expands on re-write. So: > > > > - r1.1 contains $Id$ in the repo. > > - r1.2 contains $Id: 1.1$ in t

Re: [HACKERS] SHOW TABLES

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Personally, I think this is somethign that should go into the backend ... > I'd like to be able to write perl scripts that talk to the backend without > having to remember all the various system tables I need to query / join to > get the sa

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 12:36 -0500, Kevin Grittner wrote: > I still think that the ability to issue one request and get back a > series of responses, each of which could be the result of RAISE or a > SELECT, would be valuable, and would be the best way to implement > this; but of course it would be

Re: [HACKERS] cvs to git migration - keywords

* Marko Kreen [100715 13:49]: > Eh. I stand corrected - what it actually does is even more > bizarre - it stores whatever is on the disk, but then > expands on re-write. So: > > - r1.1 contains $Id$ in the repo. > - r1.2 contains $Id: 1.1$ in the repo. > > and so on... It's actually slightl

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010, Magnus Hagander wrote: On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote: On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: Is there an actual common use-case for having these commands available for *non-psql* interfaces? There are many interfaces out there and

Re: [HACKERS] cvs to git migration - keywords

On 7/15/10, Andrew Dunstan wrote: > Marko Kreen wrote: > > On 7/7/10, Tom Lane wrote: > > > Robert Haas writes: > > > > So what happens right now using the existing git repository is that > > > > the $PostgeSQL$ tags are there, but they're unexpanded. They just > say > > > > $PostgreSQL$ ra

Re: [HACKERS] reducing NUMERIC size for 9.1

On Jul 15, 2010, at 11:58 AM, Brendan Jurd wrote: > On 10 July 2010 00:58, Robert Haas wrote: >> EnterpriseDB asked me to develop the attached patch to reduce the >> on-disk size of numeric and to submit it for inclusion in PG 9.1. >> After searching the archives, I found a possible design for th

Re: [HACKERS] SHOW TABLES

"Joshua D. Drake" wrote: > I think you guys are talking past each other. So it would appear. I was replying to a comment by Simon which sounded to me as though he didn't feel any further discussion was needed. > I believe Kevin was in fact stating that we needed to continue > discussion.

Re: [HACKERS] SHOW TABLES

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Moving it into the backend (together with the other commands) would > also solve this usabillity issue: ... > testdb \d testtable > ERROR: column "reltriggers" does not exist > LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relh

Re: [HACKERS] cvs to git migration - keywords

Marko Kreen wrote: On 7/7/10, Tom Lane wrote: Robert Haas writes: > So what happens right now using the existing git repository is that > the $PostgeSQL$ tags are there, but they're unexpanded. They just say > $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. Really? All of the

Re: [HACKERS] SHOW TABLES

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > The solution to this on some products (e.g., Sybase ASE) is to embed > such logic in stored procedures. > ...(skip other ideas)... > > I don't suppose a stored procedure implementation is in the works > anywhere? Certainly some set-returning

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010 17:09:32 +0100 Thom Brown wrote: > On 15 July 2010 17:07, Marc G. Fournier wrote: > > On Thu, 15 Jul 2010, Thom Brown wrote: > > > >> If it's only a psql problem, why implement it as SQL?  Is it just > >> so we're not adding keywords specifically to psql?  In that case, > >> i

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 19:02 +0200, Magnus Hagander wrote: > > I imagined that we would do something similar to EXPLAIN, a set of text > > rows returned. > > Wouldn't that be useless for the case when an app wants to use it? An > app will require it to be structured somehow. > > There's a reason

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 18:16 +0100, Simon Riggs wrote: > On Thu, 2010-07-15 at 11:55 -0500, Kevin Grittner wrote: > > Simon Riggs wrote: > > > > >> Having said that, I want to urge that we spend a suitable amount > > >> of time and thought and care designing this, lest it turn into a > > >> mess.

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 11:55 -0500, Kevin Grittner wrote: > Simon Riggs wrote: > > >> Having said that, I want to urge that we spend a suitable amount > >> of time and thought and care designing this, lest it turn into a > >> mess. I have no interest in slamming something through without > >> ad

Re: [HACKERS] cvs to git migration - keywords

On 7/7/10, Tom Lane wrote: > Robert Haas writes: > > So what happens right now using the existing git repository is that > > the $PostgeSQL$ tags are there, but they're unexpanded. They just say > > $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. > > > Really? All of them? Seems like

Re: [HACKERS] Per-column collation, proof of concept

On Thu, Jul 15, 2010 at 4:24 PM, Tom Lane wrote: > The problem with not doing that is it breaks hashing --- hash joins and > hash aggregation being the real pain points. > > citext works around this in a rather klugy fashion by decreeing that two > strings are equal iff their str_tolower() convers

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 18:59, Simon Riggs wrote: > On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote: >> On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote: >> > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: >> > >> >> Is there an actual common use-case for having these commands

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote: > On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote: > > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > > > >> Is there an actual common use-case for having these commands available > >> for *non-psql* interfaces? > > > > There

Re: [HACKERS] reducing NUMERIC size for 9.1

On 10 July 2010 00:58, Robert Haas wrote: > EnterpriseDB asked me to develop the attached patch to reduce the > on-disk size of numeric and to submit it for inclusion in PG 9.1. > After searching the archives, I found a possible design for this by > Tom Lane based on an earlier proposal by Simon R

Re: [HACKERS] SHOW TABLES

On 2010-07-15 18:07, Marc G. Fournier wrote: On Thu, 15 Jul 2010, Thom Brown wrote: > If it's only a psql problem, why implement it as SQL? Is it just > so we're not adding keywords specifically to psql? In that case, > it shouldn't support QUIT. Personally, I think this is somethign that s

Re: [HACKERS] SHOW TABLES

Simon Riggs wrote: >> Having said that, I want to urge that we spend a suitable amount >> of time and thought and care designing this, lest it turn into a >> mess. I have no interest in slamming something through without >> adequate consideration. > > It's OK, I wasn't asking you or anyone els

Re: [HACKERS] SHOW TABLES

Magnus Hagander wrote: > The downside is that you are then limited to what can be returned > as a resultset. A "\d table" in psql returns a hell of a lot more > than that. So do we keep two separate formats for this? Or do we > remove the current, useful, output format in favor of a much worse >

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 11:10 -0500, Robert Haas wrote: > Damn straight. I like \d as well as anyone but there are real > problems with it. Perhaps when we add \dxrvbfqS$: we'll stop to > reflect on what they are. > > Having said that, I want to urge that we spend a suitable amount of > time and t

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 13:16 -0300, Marc G. Fournier wrote: > I'd rather write: > > SHOW TABLES; > > then: > > SELECT table_name >FROM information_schema.tables > WHERE table_type = 'BASE TABLE' > AND table_schema NOT IN > ('pg_catalog', 'information_schema'); > > And, the la

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 18:35, Simon Riggs wrote: > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > >> Is there an actual common use-case for having these commands available >> for *non-psql* interfaces? > > There are many interfaces out there and people writing new ones > everyday. We

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 6:20 PM, Thom Brown wrote: > On 15 July 2010 17:16, Marc G. Fournier wrote: >> On Thu, 15 Jul 2010, Thom Brown wrote: >> >>> On 15 July 2010 17:07, Marc G. Fournier wrote: On Thu, 15 Jul 2010, Thom Brown wrote: > If it's only a psql problem, why impleme

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > Is there an actual common use-case for having these commands available > for *non-psql* interfaces? There are many interfaces out there and people writing new ones everyday. We just wrote an interface for Android, for example. It is arg

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 08:50:31AM -0700, Joshua D. Drake wrote: > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > > > > Looks like the last time this was discussed, there wasn't any clear > > > conclusion. Someone created a patch and it's still on the TODO list: > > > http://archives

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 05:38:35PM +0200, Magnus Hagander wrote: > On Thu, Jul 15, 2010 at 17:30, Thom Brown wrote: > > On 15 July 2010 16:20, Simon Riggs wrote: > >> On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: > >>> Simon Riggs writes: > >>> > The biggest turn off that most people experi

Re: [HACKERS] SHOW TABLES

On 15 July 2010 17:16, Marc G. Fournier wrote: > On Thu, 15 Jul 2010, Thom Brown wrote: > >> On 15 July 2010 17:07, Marc G. Fournier wrote: >>> >>> On Thu, 15 Jul 2010, Thom Brown wrote: >>> If it's only a psql problem, why implement it as SQL?  Is it just so we're not adding keywo

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010, Thom Brown wrote: On 15 July 2010 17:07, Marc G. Fournier wrote: On Thu, 15 Jul 2010, Thom Brown wrote: If it's only a psql problem, why implement it as SQL?  Is it just so we're not adding keywords specifically to psql?  In that case, it shouldn't support QUIT. Person

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 10:50 AM, "Joshua D. Drake" wrote: > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > >>> Looks like the last time this was discussed, there wasn't any clear >>> conclusion. Someone created a patch and it's still on the TODO list: >>> http://archives.postgresql.org

Re: [HACKERS] SHOW TABLES

On 15 July 2010 17:07, Marc G. Fournier wrote: > On Thu, 15 Jul 2010, Thom Brown wrote: > >> If it's only a psql problem, why implement it as SQL?  Is it just so we're >> not adding keywords specifically to psql?  In that case, it shouldn't >> support QUIT. > > Personally, I think this is somethig

Re: [HACKERS] SHOW TABLES

On Thu, 15 Jul 2010, Thom Brown wrote: If it's only a psql problem, why implement it as SQL? Is it just so we're not adding keywords specifically to psql? In that case, it shouldn't support QUIT. Personally, I think this is somethign that should go into the backend ... I'd like to be able

Re: [HACKERS] SHOW TABLES

As a common user -- probably a bit more than that now -- I'd have to say my reaction to '\d' instead of 'SHOW DATABASES;' was more of a "meh" moment for me. Furthermore, '\d' is much quick to type than 'SHOW DATABASES;', and much less likely to suffer typos. As for '\d' not being memorable: It

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 18:02 +0200, Guillaume Lelarge wrote: > > I have to agree with Simon here. \d is ridiculous for the common user. > > > > SHOW TABLES, SHOW COLUMNS makes a lot of sense. Just has something like > > DESCRIBE TABLE foo makes a lot more sense than \d. > > > > And would you add

Re: [HACKERS] SHOW TABLES

On 15 July 2010 16:52, Andrew Dunstan wrote: > > > Thom Brown wrote: >> >> Looks like the last time this was discussed, there wasn't any clear >> conclusion.  Someone created a patch and it's still on the TODO list: >> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php >> >> >> > >

Re: [HACKERS] SHOW TABLES

Le 15/07/2010 17:48, Joshua D. Drake a écrit : > On Thu, 2010-07-15 at 16:20 +0100, Simon Riggs wrote: >> On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: >>> Simon Riggs writes: The biggest turn off that most people experience when using PostgreSQL is that psql does not support memora

Re: [HACKERS] cvs to git migration - keywords

Hi, On 07/07/2010 08:31 PM, Andrew Dunstan wrote: Personally I favor leaving the expanded keywords in what we import, so that there's an exact mapping between what's in the final CVS repo and what's in the inital git repo, and then removing them entirely. I don't see that having old keyword expa

Re: [HACKERS] SHOW TABLES

Thom Brown wrote: Looks like the last time this was discussed, there wasn't any clear conclusion. Someone created a patch and it's still on the TODO list: http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php This is not at all what Simon proposed. He wants to make it a bac

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > > Looks like the last time this was discussed, there wasn't any clear > > conclusion. Someone created a patch and it's still on the TODO list: > > http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php > > That one is about:

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 16:20 +0100, Simon Riggs wrote: > On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: > > Simon Riggs writes: > > > The biggest turn off that most people experience when using PostgreSQL > > > is that psql does not support memorable commands. > > > > > I would like to impleme

Re: [HACKERS] standard_conforming_strings

Robert Haas writes: > On Jul 15, 2010, at 12:30 AM, Richard Huxton wrote: >> Any reason not to add a line to the 9.0 docs/release notes saying "WARNING: >> The PGDG currently plan to change this setting's default in 9.1"? > Well, mostly that we could change our mind if it makes too big a boom.

Re: [HACKERS] SHOW TABLES

On Thu, Jul 15, 2010 at 17:30, Thom Brown wrote: > On 15 July 2010 16:20, Simon Riggs wrote: >> On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: >>> Simon Riggs writes: >>> > The biggest turn off that most people experience when using PostgreSQL >>> > is that psql does not support memorable co

Re: [HACKERS] SHOW TABLES

On Jul 15, 2010, at 5:20 PM, Simon Riggs wrote: > On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: >> Simon Riggs writes: >>> The biggest turn off that most people experience when using PostgreSQL >>> is that psql does not support memorable commands. >> >>> I would like to implement the follow

Re: [HACKERS] Partitioning syntax

Simon Riggs writes: > Agreed. If all we are doing is adding synonyms for existing feature then > its not good enough. We need a new syntax that does not need to be > backwards compatible, allowing various code streamlining and more > targeting to the desired use case. Inheritance != partitioning.

Re: [HACKERS] SHOW TABLES

On 15 July 2010 16:20, Simon Riggs wrote: > On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: >> Simon Riggs writes: >> > The biggest turn off that most people experience when using PostgreSQL >> > is that psql does not support memorable commands. >> >> > I would like to implement the following

Re: [HACKERS] Per-column collation, proof of concept

Peter Eisentraut writes: > Well, the comparison function varstr_cmp() contains this comment: > /* > * In some locales strcoll() can claim that nonidentical strings are > * equal. Believing that would be bad news for a number of reasons, > * so we follow Perl's lead and sort "e

Re: [HACKERS] SHOW TABLES

On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote: > Simon Riggs writes: > > The biggest turn off that most people experience when using PostgreSQL > > is that psql does not support memorable commands. > > > I would like to implement the following commands as SQL, allowing them > > to be used fro

  1   2   >