SHOW TABLES
in [PgSql]
|
From: "Kevin Grittner" on 16 Jul 2010 17:48 "Joshua D. Drake" <jd(a)commandprompt.com> wrote: > On Sat, 2010-07-17 at 07:36 +1000, Brendan Jurd wrote: >> postgres=# SHOW ME THE MONEY; >> WARNING: THE MONEY is deprecated in this version of Postgres and >> may be discarded in a future version >> HINT: Use SHOW ME THE NUMERIC with the desired precision instead. > > Funny, but no longer true: > > http://www.postgresql.org/docs/8.4/static/datatype-money.html > > (although I wish we would get rid of the type) I hadn't been aware it was ever deprecated. It has the advantage over numeric of using straight integer arithmetic for addition and subtraction, which are by far the most common operations on money, while allowing a decimal fraction without rounding problems. I'd been thinking about migrating our money columns to it (subject to some benchmarking first, to see how much it actually helped). It would seem odd for a database to tout its ability to deal with such data types as geometric shapes and global positioning, etc., which then didn't have such a common type as money. In my experience, many business applications deal with money. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 16 Jul 2010 18:45 Le 16 juil. 2010 � 18:42, Kevin Grittner a �crit : > Like \d, these server-side stored procedures can return a number of > result sets. Like Robert, I'm skeptical of implementing a > server-side solution for PostgreSQL which doesn't do the same. I'm > not clear on whether that's even possible without a new version of > wire protocol, though. Well, I think we shouldn't mix it all. My view on that is that we need some easy simple commands in the backend, none of them on its own would mimic \d. Consider this psql command: psql -E -c '\d'. What I think is that each query you see there could easily become a SHOW subsyntax (from memory, we probably would have SHOW TABLE, SHOW INDEXES ON <table>, SHOW TRIGGERS ON <table>, SHOW CONSTRAINTS ON <table>, etc). Now, psql would be free to implement its \d in terms of those new queries rather than the full SQL ones it has now, that would be a good first client. Oh and that means the design is about all done already. And that we still are in the one command - one resultset interface. Meaning any libpq driver knows how to deal with the resultset, and that's not parsing text. I'm all with Simon here, it's not about offering any new capability that we don't already have, it's about having it handy from anywhere. So let's just have an easy syntax in the backend to do all the catalog 'magic' querying psql does, but one query at a time. Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tim Landscheidt on 16 Jul 2010 20:33 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> wrote: >>> postgres=# SHOW ME THE MONEY; >>> WARNING: THE MONEY is deprecated in this version of Postgres and >>> may be discarded in a future version >>> HINT: Use SHOW ME THE NUMERIC with the desired precision instead. >> Funny, but no longer true: >> http://www.postgresql.org/docs/8.4/static/datatype-money.html >> (although I wish we would get rid of the type) > I hadn't been aware it was ever deprecated. It has the advantage > over numeric of using straight integer arithmetic for addition and > subtraction, which are by far the most common operations on money, > while allowing a decimal fraction without rounding problems. I'd > been thinking about migrating our money columns to it (subject to > some benchmarking first, to see how much it actually helped). It > would seem odd for a database to tout its ability to deal with such > data types as geometric shapes and global positioning, etc., which > then didn't have such a common type as money. In my experience, > many business applications deal with money. One major flaw I see is that the fractional precision is fixed. Not only petrol stations split cents. Tim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 16 Jul 2010 22:08 On Fri, Jul 16, 2010 at 1:52 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > That's for MySQL. I come from a DB2 background, and when I started using > psql years ago, I often typed "LIST TABLES" without thinking much about it. > Not SHOW TABLES, but LIST TABLES. > > I bet Oracle users coming to PostgreSQL will try "DESC". Not SHOW TABLES. As > Simon listed, every DBMS out there has a different syntax for this. > > I have nothing against SHOW TABLES (it might cause conflicts in grammar > though), but if we're going to cater to people migrating from MySQL, I feel > we should cater to people migrating from other products too. But surely > we're not going to implement 10 different syntaxes for the same thing! We > could, however, give a hint in the syntax error in all those cases. That way > we're not on the hook to maintain them forever, and we will be doing people > a favor by introducing them to the backslash commands or information schema, > which are more powerful. One advantage of using LIST is that LIST doesn't already mean something else, which would simplify the grammar handling. LIST [SYSTEM | ALL] <any-object-type-in-plural-form> DESCRIBE <name-of-table> Why must the backslash commands be more powerful than any alternative we might come up with? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 17 Jul 2010 00:02
* Robert Haas (robertmhaas(a)gmail.com) wrote: > Why must the backslash commands be more powerful than any alternative > we might come up with? Because they encode alot of information in a character- something which is next to impossible to do in "english". Consider 'standard' perl vs. perl w/ 'use English;'. The former is much more condesned and the latter is much more verbose. Which would you want to use on a daily basis and which would you like to have in an application someone else may have to support some day? Next question: how long do you really think you're going to be around? :) Stephen |