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 mismatch
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 properties of an
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
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 output --- ie,
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 looking is
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 so
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
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 clear
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
away and
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 thinks
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 state we
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?
I think what I'd
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 which
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
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 here you
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
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 don't see
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
would end up
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 that default
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
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
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
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:
$ psql
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
(2323)
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 case at least),
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
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.
Which is a good thing (in
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
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
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 REPLACE
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
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 useful help. If
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 a,
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
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 release,
I
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
at the time
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) support every
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
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
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
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
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
regression=#
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 one's
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
50 matches
Mail list logo
