Bruce Momjian wrote:
Joshua D. Drake wrote:
Bruce Momjian wrote:
I moved '\g' up into the "General" section rather than make it a
single-entry section.
"send query buffer to server means nothing to a newbie". You execute
queries, you don't send buffers (from a user perspective).
Yep, good,
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >
> > test=> \?
> > General
> > \copyright show PostgreSQL usage and distribution terms
> > \g [FILE] or ; send query buffer to server (and results to file or
> > |pipe)
> > \h [NAME] help on syntax of SQL c
Bruce Momjian wrote:
test=> \?
General
\copyright show PostgreSQL usage and distribution terms
\g [FILE] or ; send query buffer to server (and results to file or
|pipe)
\h [NAME] help on syntax of SQL commands, * for all commands
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >>> My question is whether we agreed that suggesting "help" as the best way
> >>> to get help was what we agreed upon? If we did, I forgot. I thought
> >>> the 'help' ideas was just for people
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
My question is whether we agreed that suggesting "help" as the best way
to get help was what we agreed upon? If we did, I forgot. I thought
the 'help' ideas was just for people who forgot the help commands.
Please review the pr
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > My question is whether we agreed that suggesting "help" as the best way
> > to get help was what we agreed upon? If we did, I forgot. I thought
> > the 'help' ideas was just for people who forgot the help commands.
>
> Please review the previou
Bruce Momjian wrote:
> My question is whether we agreed that suggesting "help" as the best way
> to get help was what we agreed upon? If we did, I forgot. I thought
> the 'help' ideas was just for people who forgot the help commands.
Please review the previous discussion:
http://archives.postg
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I know we decided not to do that, but I am trying to figure out what the
> > goal if 'help' is? To display the most frequently-used help commands?
> > Aren't they at the top of \?.
>
> The purpose of 'help' is to provide useful help. If it onl
Bruce Momjian wrote:
> I know we decided not to do that, but I am trying to figure out what the
> goal if 'help' is? To display the most frequently-used help commands?
> Aren't they at the top of \?.
The purpose of 'help' is to provide useful help. If it only says "see \?"
then it's just redir
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
If you type 'help' it just repeats the startup banner suggestion:
test=> help
You are using psql, the command-line interface to PostgreSQL.
Type \? for help.
I think we wanted to have more inform
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Now I just realized that the current patch doesn't handle this quite
> correctly. Modified patch attached.
Applied with revisions as per discussion.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgr
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > If you type 'help' it just repeats the startup banner suggestion:
> >
> > test=> help
> >
> > You are using psql, the command-line interface to PostgreSQL.
> > Type \? for help.
>
> I think we wanted to have more information in
Bruce Momjian wrote:
> If you type 'help' it just repeats the startup banner suggestion:
>
> test=> help
>
> You are using psql, the command-line interface to PostgreSQL.
> Type \? for help.
I think we wanted to have more information in 'help', not less. Making
it just
> I think that consistency will be clearer. In the past we were trying to
> avoid \?, but I think now it is clean enough to be used by new people
> without confusion.
>
> I also put the version number in parentheses so it wouldn't be as
> prominent.
>
> Updated patch attached.
FYI, after the pa
Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 14:41:20 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Per final discussion here:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
I have looked over this patch and made a few adjustments.
You used for a he
The attached patch causes psql to use the pager if newlines or
'format=wrapped' has caused a single row to span more than one line and
the output is then too long for the screen. It also uses the pager if
psql thinks the data will wrap off the edge of the screen.
The display width as defined by
On Wed, May 14, 2008 at 3:47 PM, daveg <[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>>
>> One idea would be to add the libpq hooks but not document them. This
>> way, we can modify or remove the API as needed in the future. As
>> libpqtypes matures a
On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>
> One idea would be to add the libpq hooks but not document them. This
> way, we can modify or remove the API as needed in the future. As
> libpqtypes matures and we are sure what the API should be, we can
> document it as stable a
Attached is an updated patch. The only change to this patch is that
hookNames are now compared with strcmp rather than strcasecmp. The
comparisons occur in fe-mics.c (bottom of file) during PQhookData and
PQresultHookData.
Not sure this needs clarification, but PQcopyResult, PQresultAlloc an
Merlin Moncure wrote:
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm wondering why the hooks need names at all. AFAICS all that
libpq needs to know about a hook is a callback function address
and a void * passthrough pointer.
For reference...here is what libpqtypes
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm wondering why the hooks need names at all. AFAICS all that
> libpq needs to know about a hook is a callback function address
> and a void * passthrough pointer.
For reference...here is what libpqtypes has to do to bind vi
I'm wondering why the hooks need names at all. AFAICS all that
libpq needs to know about a hook is a callback function address
and a void * passthrough pointer.
In question is:
+ void *
+ PQhookData(const PGconn *conn, const char *hookName)
Basically, libpqtypes has various functions that tak
On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>> Regarding the other comments:
>> *) API structure: Our major objective was to minimize exports to
>> libpq. I think both copyresult and setvalue have some possible
>> sideband usage (footguns or n
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, they could revise their patch to be more stylistically in keeping
> with libpq. I haven't looked at the current version of the patch yet,
> but the early versions seemed quite overengineered to me, so your
> criticism didn
Merlin Moncure wrote:
> Regarding the other comments:
> *) API structure: Our major objective was to minimize exports to
> libpq. I think both copyresult and setvalue have some possible
> sideband usage (footguns or no). Additional functions could be
> speculated but are not required by libpqtype
On Tue, May 13, 2008 at 11:52 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> My personal opinion is still that I would like to see a more general
> usefulness for these functions before adding them to libpq. The
> complexity of the API just mirrors my gut feeling on this.
There has been a lot of
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It should be noted that while this feels slightly foreign, it isn't
> hugely invasive, unlike the previous effort - it's only a few hundred
> lines of new code.
> If we reject this, presumably the authors will have no alternative than
> to offer libp
On Wed, May 14, 2008 at 8:18 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Right, it was more the case insensitive part that bothered me.
Done. We in fact had realized this was a mistake anyways following
some profiling of the libpqtypes library. In some scenarios, this
function gets called a l
> What I think we should do about that is forget tracking getrusage()'s
> user/system/real time and just track elapsed time. We have the
> technology to get that in a portable fashion (cf the well-proven
> instrument.c code). Such a decision would also alleviate two of the
> biggest negatives of
Alvaro Herrera wrote:
Andrew Dunstan escribió:
The thing that is a bit disturbing is that the whole style of this
scheme is very different from the fairly simple APIs that the rest of
libpq presents. It's going to make libpq look rather odd, I think. I
would have felt happier if the a
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Shouldn't we at least make it fail with EINVAL if "who" doesn't match
whichever semantics this code is able to implement?
Yeah, we only ever call it asking for our own process, but I guess we
might at some point in t
31 matches
Mail list logo
