Josh Berkus wrote:
>
> >> My problem with this whole idea is that it seems to be very MySQL-specific.
> >> Why aren't we providing help for users migrating from Oracle, Sybase,
> >> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
> >> turn all those on by default, we'll
Baron,
> Hypothetically, if I had time to help with something like that, is
> there a wiki or something where I could help draft it, without needing
> to get all elbows-deep into the documentation itself?
wiki.postgresql.org.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Josh,
On Mon, Jan 25, 2010 at 1:47 PM, Josh Berkus wrote:
>
>>> My problem with this whole idea is that it seems to be very MySQL-specific.
>>> Why aren't we providing help for users migrating from Oracle, Sybase,
>>> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
>>>
>> My problem with this whole idea is that it seems to be very MySQL-specific.
>> Why aren't we providing help for users migrating from Oracle, Sybase,
>> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
>> turn all those on by default, we'll have a pretty horrible banne
On Mon, Jan 25, 2010 at 1:05 PM, Baron Schwartz wrote:
> Hi Robert,
>
> On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
>> Maybe instead of (or in addition to) providing MySQL-specific help, we
>> should find a way to emphasize the "\d" and "\d table" commands,
>
> Right, it's like "cd" and
Hi Robert,
On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
> Maybe instead of (or in addition to) providing MySQL-specific help, we
> should find a way to emphasize the "\d" and "\d table" commands,
Right, it's like "cd" and "ls" at the shell prompt. It's like walking
into a dark room and
Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > probably not bug anyone enough to turn it of
Ross J. Reedstrom wrote:
So a quick mapping of most-needed commands, and a pointer to the docs for the
full
ramifications and subtle differences seems to fit the existing
documentation module.
And that's been done at least twice already:
http://blog.endpoint.com/2009/12/mysql-and-postgres-
On Mon, Jan 25, 2010 at 10:49:55AM -0600, Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > pr
On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
<..>
> without having to add a switch to their command lines. It's not going
> to have anything to say to experienced psql users anyway so it would
> probably not bug anyone enough to turn it off.
I would so use this feature goi
On Mon, Jan 25, 2010 at 11:14 AM, Andrew Dunstan wrote:
> Alastair "Bell" Turner wrote:
>>
>> If this option is designed to help people's transition - basically to
>> get to them before they've got to most of the manual - having to turn
>> it on will be pointless. It needs to be active by default.
On Mon, Jan 25, 2010 at 6:14 PM, Andrew Dunstan wrote:
>
> My problem with this whole idea is that it seems to be very MySQL-specific.
> Why aren't we providing help for users migrating from Oracle, Sybase,
> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
> turn all th
Alastair "Bell" Turner wrote:
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default.
My problem with this whole idea is that it seems to be very
M
* Alastair Bell Turner [100125 11:07]:
> If this option is designed to help people's transition - basically to
> get to them before they've got to most of the manual - having to turn
> it on will be pointless. It needs to be active by default. A way to
> avoid it being a default option in psql may
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default. A way to
avoid it being a default option in psql may be setting an alias as
part of package installa
2010/1/25 Baron Schwartz :
> Hi Cédric,
>
> On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain
> wrote:
>> 'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a
>> special helper : I don't see the point to introduce that kind of
>> things when it is useless for most of our users.
>
Hi Cédric,
On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain
wrote:
> 'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a
> special helper : I don't see the point to introduce that kind of
> things when it is useless for most of our users.
I think it's good to go beyond what's
2010/1/24 Baron Schwartz :
> David Fetter just pointed this thread out to me. I think anything
> that makes PostgreSQL more accessible could be a good thing. In some
> sense it's harder to learn a technology when you are very familiar
> with another similar one already. Is it easier to learn to
David Fetter just pointed this thread out to me. I think anything
that makes PostgreSQL more accessible could be a good thing. In some
sense it's harder to learn a technology when you are very familiar
with another similar one already. Is it easier to learn to type on
Dvorak, or to learn QWERTY
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
the
ereport output
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 the
> ereport output from the server.
No. Not unless you w
2010/1/21 David Christensen :
>
> 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
>>> ma
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 use
* 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 use some improvement, open to
> suggest
Tom Lane writes:
> The proposed patch to just provide a helpful message
> is only a dozen or two lines, which is about the right amount of effort
> to expend in this direction IMHO.
For the record, agreed on the commands for which we have no obvious
equivalent :)
Regards,
--
Dimitri Fontaine
Dimitri Fontaine writes:
> I'll give my vote to Peter's idea that show tables; should better act as
> if you typed \d.
We have previously considered and rejected this type of approach, for
example in the pgsql-bugs discussion I referenced upthread.
> I don't see what the gain is to refuse being
I would personally emulate \d and take the chance for showing a funny
warning, something like: "hey, it's not MySql!" or similar. I am sure
we will Finder something appropriate. :)
Inviato da iPhone
Il giorno 20/gen/2010, alle ore 16.30, "Kevin Grittner" > ha scritto:
Dimitri Fontaine wr
Dimitri Fontaine wrote:
> I'll give my vote to Peter's idea that show tables; should better
> act as if you typed \d.
I guess we don't need a "tables" GUC. Show all wouldn't include it?
Would we require a semicolon? Do we support \d-style globs?
Still seems kinda messy. +1 for help to sho
Dimitri Fontaine wrote:
> Robert Haas writes:
> > If what the user wanted was to be using MySQL, he is out of luck
> > anyway.
>
> That's not what we're talking about. We're talking about having a nice
> client tool for those people having to do both MySQL and PostgreSQL
> support, or new to Post
Robert Haas writes:
> If what the user wanted was to be using MySQL, he is out of luck
> anyway.
That's not what we're talking about. We're talking about having a nice
client tool for those people having to do both MySQL and PostgreSQL
support, or new to PostgreSQL and comming from MySQL.
I'll g
Robert Haas wrote:
I'm actually no big advocate of the \d commands. They're basically
magical queries that you can't easily see or edit - I've more than
once wished for a WHERE clause (\df WHERE "Result data type" =
'internal' or what have you.
You *can* easily see them, at least. Run "
On Wed, Jan 20, 2010 at 9:26 AM, Peter Eisentraut wrote:
> On ons, 2010-01-20 at 09:05 -0500, Bruce Momjian wrote:
>> I disagree. No one has complained that we are being a "smartass" by
>> reporting this for "help" in psql:
>>
>> You are using psql, the command-line interface to PostgreS
On Wed, Jan 20, 2010 at 9:05 AM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On tis, 2010-01-19 at 16:00 -0600, David Christensen wrote:
>> > Currently, a session will look like the following:
>> >
>> > machack:machack:5485=# show tables;
>> > See:
>> > \d
>> > or \
On ons, 2010-01-20 at 09:05 -0500, Bruce Momjian wrote:
> I disagree. No one has complained that we are being a "smartass" by
> reporting this for "help" in psql:
>
> You are using psql, the command-line interface to PostgreSQL.
> Type: \copyright for distribution terms
>
Peter Eisentraut wrote:
> On tis, 2010-01-19 at 16:00 -0600, David Christensen wrote:
> > Currently, a session will look like the following:
> >
> >machack:machack:5485=# show tables;
> >See:
> > \d
> > or \? for general help with psql commands
> >machack:machack:54
On tis, 2010-01-19 at 16:00 -0600, David Christensen wrote:
> 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=#
I think if you make "show tables"
On tis, 2010-01-19 at 11:43 -0800, Jeff Davis wrote:
> I'll make an analogy to:
>
> $ git difff
> git: 'difff' is not a git-command. See 'git --help'.
>
> Did you mean this?
> diff
This is presumably spelling-based, which might be an interesting feature
(although probably useless
this is mostly true. I don't think any Oracle DBA will expect ALL_TABLES our
DBA_TABLES to be there.
however DESCRIBE and HELP would be the two that come to mind.
greg
On 20 Jan 2010 02:56, "Greg Sabino Mullane" wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Why would they want
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Why would they want more? It's not MySQL, and they know that.
> If we give them some very minor helpful hints for the most
> common things they try to d
On 20/01/2010 6:31 AM, Rob Wultsch wrote:
As a MySQL DBA the commands I think are most useful are:
show databases (please punt this, most MySQL dba's that I have worked
with will need to consider the difference between a db and a schema)
use database (please punt)
So perhaps for SHOW DATABASES
Robert Haas writes:
> Although the deadline for patches for 8.5 has supposedly already passed
I guess it already got more review than some of the commit fest items
already…
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Tue, Jan 19, 2010 at 3:14 PM, David E. Wheeler wrote:
> On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
>
>> I thought Magnus had a really good point: covering these four cases will
>> probably be enough to teach newbies to look at psql's backslash
>> commands. And once they absorb that, we're ov
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 most common things they try to do, it
> would be a huge benefit to them. I know I've badly wanted the opposite when
>
On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
> I thought Magnus had a really good point: covering these four cases will
> probably be enough to teach newbies to look at psql's backslash
> commands. And once they absorb that, we're over a big hump.
+1
On Jan 19, 2010, at 1:57 PM, Devrim GÜNDÜZ w
On Jan 19, 2010, at 3:57 PM, Devrim GÜNDÜZ wrote:
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
I like that idea. There may be a lot of MySQL people that want to use
the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should le
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 p
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
> I like that idea. There may be a lot of MySQL people that want to use
> the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should learn our
syntax. How can you make sure that this wil
David Christensen writes:
> On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
>> Quite apart from any considerations covered by other people, these
>> two at least could be positively misleading ... the psql commands
>> are not exact equivalents of the MySQL commands, AIUI.
> The \copy could
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 partial replacements for some of thos
David Christensen wrote:
Quite apart from any considerations covered by other people, these
two at least could be positively misleading ... the psql commands are
not exact equivalents of the MySQL commands, AIUI.
The \copy could definitely be considered a stretch; I know \c supports
more
On Jan 19, 2010, at 12:58 PM, Stefan Kaltenbrunner wrote:
> well providing a hint that one should use different command will only lead to
> the path "uhm why not make it work as well"
I don't think so. People know it's a different database. They'd be thrilled
just to get the hint. I think it's
On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (M
On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind
of a
prefix anyway to avoid conflicting with actual SQL... maybe
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (MYSQL_HELP_CHECK("load data infile"))
+
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind of a
prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
that defeats a lot of the purpose.
Yeah, requiring
Tom Lane wrote:
> Jeff Davis writes:
> > That being said, I don't have much of an opinion, so if you see a
> > problem, then we can forget it. After all, we would need some kind of a
> > prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> > that defeats a lot of the purpose.
>
The previous discussion started from the idea that only DESCRIBE,
SHOW DATABASES/TABLES, and USE were worth worrying about. If we
were to agree that we'd go that far and no farther, the potential
conflict with SQL syntax would be pretty limited. I have little
enough experience with mysql to not
On Tue, Jan 19, 2010 at 21:44, Tom Lane wrote:
> Jeff Davis writes:
>> That being said, I don't have much of an opinion, so if you see a
>> problem, then we can forget it. After all, we would need some kind of a
>> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
>> that defe
Jeff Davis writes:
> That being said, I don't have much of an opinion, so if you see a
> problem, then we can forget it. After all, we would need some kind of a
> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> that defeats a lot of the purpose.
Yeah, requiring a prefix wo
On Tue, 2010-01-19 at 20:52 +0100, Stefan Kaltenbrunner wrote:
> Jeff Davis wrote:
> >> I'm not convinced that we should start adding syntax helpers like that
> >> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> >> to add oracle/db2/mssql/drizzle/mariadb and whatnot late
David Christensen escreveu:
> I whipped up a quick patch for supporting some of the common mysql-based
> "meta" commands; this is different than some things which have been
> discussed in the past, in that it provides just a quick direction to the
> appropriate psql command, not an actual alternati
Jeff Davis wrote:
I'm not convinced that we should start adding syntax helpers like that
to psql. For now it is an arbitrary subset of MySQL stuff, are we going
to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
Also I can already see people asking "well you already know that this is
On Tue, 2010-01-19 at 11:43 -0800, Jeff Davis wrote:
> > I'm not convinced that we should start adding syntax helpers like that
> > to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> > to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> > Also I can already see
> I'm not convinced that we should start adding syntax helpers like that
> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> Also I can already see people asking "well you already know that this is
> that com
Jeff Davis wrote:
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick d
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
> Hey -hackers,
>
> I whipped up a quick patch for supporting some of the common mysql-
> based "meta" commands; this is different than some things which have
> been discussed in the past, in that it provides just a quick direction
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick direction
to the appropriate psql command, not an actual alternative syntax for
67 matches
Mail list logo
