Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ah, OK. I had forgotten. Here is the new output:
> $ sql test
> psql (8.4devel) Type "help" for help.
> test=> help
You are being unreasonably cryptic here. What happens when there
is optional output --- ie, version misma
On Sat, 10 May 2008 09:36:26 +0200 Andreas 'ads' Scherbaum wrote:
> On Sat, 3 May 2008 21:12:51 +0200 Andreas 'ads' Scherbaum wrote:
> > On Sat, 03 May 2008 13:34:05 -0400 Tom Lane wrote:
> >
> > > So maybe the right thing is that CREATE OR REPLACE LANGUAGE can change
> > > "inessential" properti
Andreas 'ads' Scherbaum wrote:
Attached is another version of the patch (still missing documentation),
which changes the language owner on update (the owner can still be
changed in pg_pltemplate).
The other CREATE OR REPLACE commands don't change the owner, so CREATE
OR REPLACE LANGUAGE should
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ah, OK. I had forgotten. Here is the new output:
>
> > $ sql test
> > psql (8.4devel) Type "help" for help.
>
> > test=> help
>
> You are being unreasonably cryptic here. What happens when there
> is optional
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, good point. Let me look at that. Thanks. You prefer:
> $ sql test
> psql (8.4devel)
> Type "help" for help.
> test=> help
Well, the question is still "where is the optional info going to go?"
I think what I'd find nice l
Tom Lane wrote:
Well, the question is still "where is the optional info going to go?"
I think what I'd find nice looking is
$ psql test
psql 8.4devel [ server version warning here, if needed ]
[ line with SSL info here, if needed ]
Type "help" for help.
test=
Joshua D. Drake wrote:
> O.k. I am not trying to start an argument here but... I already sent 6
> revisions of this patch that received comments and had thorough review
> via Alvaro. I even took into account Tom's original comments from the
> previous thread.
>
> This much effort on something s
Joshua D. Drake wrote:
O.k. I am not trying to start an argument here but... I already sent 6
revisions of this patch that received comments and had thorough review
via Alvaro. I even took into account Tom's original comments from the
previous thread.
This much effort on something so simp
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.
I'm trying to make this work as you suggest.
It's pretty cl
On Thu, 15 May 2008 11:46:41 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Bruce with respect the only useful thing I have seen you do to the
> > patch in all this wrangling is realign the \? General options and
> > frankly even that is suspect in my opinion. Can we either throw it
> >
Andrew Dunstan wrote:
> Welcome to UI development. There is always *far* more argument of minor
> matters of appearance than over anything else, in my experience.
Which is a good thing (in this case at least), because otherwise we
would end up with a crappy UI just because a single person think
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The problem is the functions PQhookData(conn, hookname) and
> PQresultHookData(result, hookName). We need these to work in
> functions that are not callbacks. If we eliminate hookname
> completely, there is no way for libpq to know which private stat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, good point. Let me look at that. Thanks. You prefer:
>
> > $ sql test
> > psql (8.4devel)
> > Type "help" for help.
>
> > test=> help
>
> Well, the question is still "where is the optional info going to go?"
>
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Welcome to UI development. There is always *far* more argument of minor
matters of appearance than over anything else, in my experience.
Which is a good thing (in this case at least), because otherwise we
would end up with a crappy UI just because
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
The problem is the functions PQhookData(conn, hookname) and
PQresultHookData(result, hookName). We need these to work in
functions that are not callbacks. If we eliminate hookname
completely, there is no way for libpq to know wh
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
The problem is the functions PQhookData(conn, hookname) and
PQresultHookData(result, hookName). We need these to work in
functions that are not callbacks. If we eliminate hookname
completely, there is no way for libpq to know which p
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It might work to use the address of the hook callback function as
>> a key for retrieving the associated void * pointer. You'd need to
>> not register the same callback function more than once per object,
>> but from what I gather her
Andrew Chernow <[EMAIL PROTECTED]> writes:
> There can be cases to use the same callbacks, although unlikely. To
> completely avoid collisions, the below would work:
Still looks like overdesign to me. If we use the hook function address
we solve the problem with no extra notation and no extra s
Andrew Dunstan wrote:
Tom Lane wrote:
It might work to use the address of the hook callback function as
a key for retrieving the associated void * pointer. You'd need to
not register the same callback function more than once per object,
but from what I gather here you don't need to.
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Looking at this now. Wouldn't it be a good idea for comparePartial
>> to get the strategy number of the operator? As you have it set up,
>> I doubt that an opclass can support more than one partial-match
>> operator.
> It might be useful, although I d
Ron Mayer wrote:
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> >
> >> Welcome to UI development. There is always *far* more argument of minor
> >> matters of appearance than over anything else, in my experience.
> >
> > Which is a good thing (in this case at least), because otherwise we
>
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
There can be cases to use the same callbacks, although unlikely. To
completely avoid collisions, the below would work:
Still looks like overdesign to me. If we use the hook function address
we solve the problem with no extra notation
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ron Mayer wrote:
>> This makes me think we shouldn't be hard-coding anything at all
>> as the welcome message; but rather having a default .psqlrc
>> in much the same way that that there's a default /etc/bash.bashrc
>> and /etc/csh.login.
>>
>> Within th
I'm OK with thisG but please move the printSSLInfo() call just before
echoing the help line.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To mak
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Which callback do we use as the key? Currently, none are required (only
> the name was required). We have to choose one callback that must be
> provided.
What? I thought what you wanted back was the void * pointer that had
been registered with a pa
This patch adds the ability to specify client certification and keys as
well as root certificates and revocation lists for the client as
parameters in PQconnectdb()
sslkey=fullepath_to_file
sslcert=fullpath_to_cert
ssltrustcrt=fullpath_to_trusted_cert_file
sslcrl=fullpath_to_revocation_list
Also,
Alvaro Herrera wrote:
>
> I'm OK with thisG but please move the printSSLInfo() call just before
> echoing the help line.
Oh, good catch, moved. I also moved the Win32 code page message up too.
Patch attached.
I hacked up an example that shows both SSL and Win32 code page messages:
$ ps
Bruce Momjian <[EMAIL PROTECTED]> writes:
> With major version mismatches it looks like this:
> $ psql test
> psql (8.4devel)
> SSL connection (cipher: 2343, bits: 512)
> WARNING: Console code page (323) differs from Windows code page
> (2323)
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > With major version mismatches it looks like this:
>
> > $ psql test
> > psql (8.4devel)
> > SSL connection (cipher: 2343, bits: 512)
> > WARNING: Console code page (323) differs from Windows code page
On Thu, May 15, 2008 at 10:20:53AM -0700, Ron Mayer wrote:
> Alvaro Herrera wrote:
> >Andrew Dunstan wrote:
> >
> >>Welcome to UI development. There is always *far* more argument of minor
> >>matters of appearance than over anything else, in my experience.
> >
> >Which is a good thing (in this ca
It might be useful, although I don't see any usage of that right now. I'll add
this option.
Ping? I'd like to get this patch out of the way.
I'm very sorry for long delay.
http://www.sigaev.ru/misc/partial_match_gin-0.10.gz
http://www.sigaev.ru/misc/tsearch_prefix-0.8.gz
http://www.sigaev.ru/
daveg wrote:
> On Thu, May 15, 2008 at 10:20:53AM -0700, Ron Mayer wrote:
> > Alvaro Herrera wrote:
> > >Andrew Dunstan wrote:
> > >
> > >>Welcome to UI development. There is always *far* more argument of minor
> > >>matters of appearance than over anything else, in my experience.
> > >
> > >Whic
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Which callback do we use as the key? Currently, none are required (only
the name was required). We have to choose one callback that must be
provided.
What? I thought what you wanted back was the void * pointer that had
been registe
On Thu, May 15, 2008 at 12:09:25PM -0400, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
> > Welcome to UI development. There is always *far* more argument of minor
> > matters of appearance than over anything else, in my experience.
>
> Which is a good thing (in this case at least), because o
On Thu, 15 May 2008 12:29:11 +0100 Heikki Linnakangas wrote:
> Andreas 'ads' Scherbaum wrote:
> > Attached is another version of the patch (still missing documentation),
> > which changes the language owner on update (the owner can still be
> > changed in pg_pltemplate).
>
> The other CREATE OR R
Following the conclusion here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00273.php
here's a patch that extends VacAttrStats to allow typanalyze functions
to store statistic values of different types than the underlying column.
The XXX comment can be taken into consideration or jus
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> 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 usef
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I am sending little bit smarter version - without redundant parsing.
Applied with corrections --- you had some memory management problems
in particular.
One thing that I think might annoy people is that you've handled
CASE x
WHEN
Jan Urbański wrote:
Following the conclusion here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00273.php
here's a patch that extends VacAttrStats to allow typanalyze functions
to store statistic values of different types than the underlying column.
The XXX comment can be taken into
David Fetter wrote:
I hate to bike-shed this even further, but I'd like to make those
"incompatibility" messages just go away by making 8.4's psql (and all
those going forward) support every living version of Postgres at the
time of their release, so 8.4's psql would be able to talk seamlessly
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> David Fetter wrote:
>> I hate to bike-shed this even further, but I'd like to make those
>> "incompatibility" messages just go away by making 8.4's psql (and all
>> those going forward) support every living version of Postgres at the
>> time of their rel
On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
>>
>> I hate to bike-shed this even further, but I'd like to make those
>> "incompatibility" messages just go away by making 8.4's psql (and
>> all those going forward) support every living version of Postgres
>>
On Thu, May 15, 2008 at 06:57:12PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > David Fetter wrote:
> >> I hate to bike-shed this even further, but I'd like to make those
> >> "incompatibility" messages just go away by making 8.4's psql (and
> >> all those going forward)
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Which callback do we use as the key? Currently, none are required (only
the name was required). We have to choose one callback that must be
provided.
What? I thought what you wanted back was the void * pointer that had
been registe
David Fetter wrote:
On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
I hate to bike-shed this even further, but I'd like to make those
"incompatibility" messages just go away by making 8.4's psql (and
all those going forward) support every living ver
Andrew Dunstan wrote:
> Second, it's not nearly as easy as that:
> . new commands have been added
> . postgres features have been added
> . catalogs have changed
Well, this just means a different piece of SQL needs to be sent for a
command depending on the server version, right? It's not like th
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Second, it's not nearly as easy as that:
. new commands have been added
. postgres features have been added
. catalogs have changed
Well, this just means a different piece of SQL needs to be sent for a
command depending on the server versi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/partial_match_gin-0.10.gz
> http://www.sigaev.ru/misc/tsearch_prefix-0.8.gz
> http://www.sigaev.ru/misc/wildspeed-0.12.tgz
There seems to be something broken here: it's acting like prefix search
is on all the time, eg
regressio
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Have at it then. Prove me wrong.
> IMO the problem isn't the one off support for all supported version of
> Pg... say 7.4 -> 8.4. The problem is of on going maintenance.
> /me doesn't think it is worth the effort.
Since no
Andrew Dunstan wrote:
And for commands that have been added later, an initial version could
just say "this server version does not support this command". It would
be already a huge improvement.
Probably the biggest change would be to support versions that did not
have schemas, but I think it w
50 matches
Mail list logo
