On tor, 2010-07-15 at 05:57 +0200, Pavel Stehule wrote:
:( maybe we have to enhance a locales - or do some work in this way.
In Czech's IS is relative often operation some like
name = 'Stěhule' COLLATION cs_CZ_cs_ai -- compare case insensitive
accent insensitive
PostgreSQL is last db,
On Thu, 2010-07-08 at 07:16 +0100, Simon Riggs wrote:
I'll take my previous patch through to completion now
Patch to reduce lock levels for
ALTER TABLE
CREATE TRIGGER
CREATE RULE
I've completely re-analyzed the required lock levels for sub-commands,
so lock levels can now also be these, if
hello ...
a view is already nice but i think it is still too narrow.
the problem is: you don't want a view for every potential join.
in addition to that - ideally there is not much left of a view when it comes to
checking for costs.
so, i think, this is not the kind of approach leading to total
On Tue, 2010-07-06 at 13:49 -0400, Robert Haas wrote:
1. It seems to me that the proposed design for pg_partition is poorly
thought out. In particular, I don't see how this would work if we
wanted to partition on multiple keys, which is a feature supported by
both Oracle and MySQL. It would
On Jul 15, 2010, at 12:30 AM, Richard Huxton d...@archonet.com wrote:
On 14/07/10 15:48, Robert Haas wrote:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkusj...@agliodbs.com wrote:
An actual plan here might look like let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it
On Thu, Jul 15, 2010 at 12:04:21PM +0200, Hans-Jürgen Schönig wrote:
hello ...
a view is already nice but i think it is still too narrow.
the problem is: you don't want a view for every potential join.
in addition to that - ideally there is not much left of a view when it comes
to
Hi,
We've been talking about this topic on -performance:
Markus Wanner mar...@bluegap.ch writes:
I've combined these two components into a single, general purpose background
worker infrastructure component, which is now capable to serve autovacuum as
well as Postgres-R. And it might be of use
On Thu, Jul 15, 2010 at 12:04:21PM +0200, Hans-Jürgen Schönig wrote:
hello ...
a view is already nice but i think it is still too narrow.
One sure way to fail is to take on a problem in chunks too large. If
we get even one of the cross-column issues solved by statistics, we'll
be ahead of
/me bangs gavel
I hereby declare the 2010-07 CommitFest closed to further patch
submissions, as it is now officially In Progress. We have one
month to provide initial review of the patches which have
accumulated since the start of the last CommitFest, six months ago,
and hopefully get a
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 from any interface.
SHOW TABLES
SHOW COLUMNS
SHOW DATABASES
...
SHOW [FULL] any object type
Simon Riggs si...@2ndquadrant.com 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 from any interface.
SHOW TABLES
SHOW COLUMNS
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Peter Eisentraut pete...@gmx.net 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
On 15 July 2010 16:20, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The biggest turn off that most people experience when using PostgreSQL
is that psql does not support memorable commands.
I would
Simon Riggs si...@2ndquadrant.com 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
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 si...@2ndquadrant.com 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
On Thu, Jul 15, 2010 at 17:30, Thom Brown thombr...@gmail.com wrote:
On 15 July 2010 16:20, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The biggest turn off that most people experience when using
Robert Haas robertmh...@gmail.com writes:
On Jul 15, 2010, at 12:30 AM, Richard Huxton d...@archonet.com 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
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 si...@2ndquadrant.com writes:
The biggest turn off that most people experience when using PostgreSQL
is that psql does not support memorable commands.
I would like to
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:
a)
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
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
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 si...@2ndquadrant.com writes:
The biggest turn off that most people experience when using PostgreSQL
is that psql does not
On 15 July 2010 16:52, Andrew Dunstan and...@dunslane.net 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
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 the
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
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
On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org 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
On Jul 15, 2010, at 10:50 AM, Joshua D. Drake j...@commandprompt.com 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:
On Thu, 15 Jul 2010, Thom Brown wrote:
On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org 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
On 15 July 2010 17:16, Marc G. Fournier scra...@hub.org wrote:
On Thu, 15 Jul 2010, Thom Brown wrote:
On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org 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
On Thu, Jul 15, 2010 at 05:38:35PM +0200, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 17:30, Thom Brown thombr...@gmail.com wrote:
On 15 July 2010 16:20, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
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:
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
On Jul 15, 2010, at 6:20 PM, Thom Brown wrote:
On 15 July 2010 17:16, Marc G. Fournier scra...@hub.org wrote:
On Thu, 15 Jul 2010, Thom Brown wrote:
On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org wrote:
On Thu, 15 Jul 2010, Thom Brown wrote:
If it's only a psql problem, why
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com 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
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 latter, unless
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
Magnus Hagander mag...@hagander.net 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
Simon Riggs si...@2ndquadrant.com 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
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
On 10 July 2010 00:58, Robert Haas robertmh...@gmail.com 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
On Thu, Jul 15, 2010 at 18:59, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote:
Is there an actual common
On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com 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?
On Thu, Jul 15, 2010 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us 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
On 7/7/10, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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$.
On Thu, 2010-07-15 at 11:55 -0500, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com 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
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 si...@2ndquadrant.com 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
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 we made
On Thu, 15 Jul 2010 17:09:32 +0100 Thom Brown wrote:
On 15 July 2010 17:07, Marc G. Fournier scra...@hub.org 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,
-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
Marko Kreen wrote:
On 7/7/10, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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:
-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, relhasr...
Joshua D. Drake j...@commandprompt.com 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
On Jul 15, 2010, at 11:58 AM, Brendan Jurd dire...@gmail.com wrote:
On 10 July 2010 00:58, Robert Haas robertmh...@gmail.com 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,
On 7/15/10, Andrew Dunstan and...@dunslane.net wrote:
Marko Kreen wrote:
On 7/7/10, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So what happens right now using the existing git repository is that
the $PostgeSQL$ tags are there, but they're
On Thu, 15 Jul 2010, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com 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
* Marko Kreen mark...@gmail.com [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
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
-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 same
* Aidan Van Dyk ai...@highrise.ca [100715 13:56]:
* Marko Kreen mark...@gmail.com [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
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
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
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_schema in
On Jul 15, 2010, at 11:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote:
Is there an actual common
-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 to
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
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 Contributor
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
--On 15. Juli 2010 18:02:10 +0200 Guillaume Lelarge
guilla...@lelarge.info 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
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
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
On 15/07/10 19:44, Robert Haas wrote:
On Jul 15, 2010, at 11:59 AM, Simon Riggssi...@2ndquadrant.com
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
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 SHOW
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
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
Bernd Helmle wrote:
--On 15. Juli 2010 18:02:10 +0200 Guillaume Lelarge
guilla...@lelarge.info 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
-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
of
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
Kaare Rasmussen ka...@jasonic.dk 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
On Thu, Jul 15, 2010 at 1:28 PM, Markus Wanner mar...@bluegap.ch 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.
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
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 could
--On 15. Juli 2010 15:52:24 -0400 Andrew Dunstan and...@dunslane.net
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
http://msdn.microsoft.com/en-us/library/ms182764.aspx
Yeah,
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
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. That
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 mar...@bluegap.ch 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
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 detracts
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
On Jul 15, 2010, at 2:26 PM, Richard Huxton d...@archonet.com 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
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
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 regularly
use
Le 15 juil. 2010 à 18:43, Magnus Hagander mag...@hagander.net 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,
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
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 guessable for
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
Andrew Dunstan and...@dunslane.net 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
Brent Dombrowski brent.dombrow...@gmail.com 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:
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
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 TABLES is
1 - 100 of 109 matches
Mail list logo
