Re: [PATCHES] Patch to change psql default banner v6
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 would be OK to punt on that. We already stopped supporting 7.2 anyway. 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. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
"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 done it yet, that would seem to be the consensus opinion :-) Still, it'd be interesting to see an attempt at making it go. The costs of doing it now for existing versions would probably give us a good idea of what the future maintenance effort might be like. Without a real patch to look at, we're all just guessing about that. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Partial match in GIN (next vesrion)
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=# select 'supernova'::tsvector @@ 'super'::tsquery; ?column? -- t (1 row) regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 version, right? It's not like that's tremendously different. The nice thing about most \X commands is that they embed everything they need in a bunch of SQL, and they don't need much else in C code. So it's not all that difficult. 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 would be OK to punt on that. We already stopped supporting 7.2 anyway. Have at it then. Prove me wrong. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 that's tremendously different. The nice thing about most \X commands is that they embed everything they need in a bunch of SQL, and they don't need much else in C code. So it's not all that difficult. 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 would be OK to punt on that. We already stopped supporting 7.2 anyway. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 version of Postgres at the time of their release, so 8.4's psql would be able to talk seamlessly to Postgres 7.4 :) I think you must have been out in the sun too long. One thing I really treasure about working on the Postgres project is frank feedback. :) I know you know me well enough to realise there was an implied smiley ;-) Just look at the pg_dump code if you want something of an idea of what this would involve. Given that each previous version tied backslash commands to some particular chunk of SQL, what would be the problem with either immediately or lazily setting those to the chunks of SQL already present in previous versions? First, this is not a cost free exercise - it increases code complexity enormously. Second, it's not nearly as easy as that: . new commands have been added . postgres features have been added . catalogs have changed Among other things, help and indeed the available command set would have to become server version sensitive. And you would greatly increase the bar for anyone wanting to add a new command - now they (or someone) would have to work out how the command would or might work n versions back, not just with the current dev version. Doing it lazily isn't acceptable - if we promise \command compatibility with previous server versions then we need to deliver it to the maximum extent possible, and if we don't promise it there's no point in doing this. And, as Tom says, it has nothing really to do with this patch. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 registered with a particular callback function. So you use that
callback function. If it's not actually registered, you get a NULL.
This is what is passed to PQaddObjectHooks, along with a conn:
This is all wrong IMHO, not least because it creates ABI problems if you
want to add another hook type later. Register each hook separately, eg
typedef void (*PGCRHook) (PGconn *conn, void *passthrough);
void PQregisterConnResetHook(PGconn *conn, PQCRHook func, void *passthrough);
... repeat for each possible hook ...
regards, tom lane
I am starting to think we have not clarified what it is we are trying to
do; maybe hook is the wrong terminology.
We need to add members to a conn and result, that's pretty much it. To
do this, an api user can register callbacks to receive notifications
about created/destroyed states of objects. PQhookData is just like
PQerrorMessage in that both are public accessor functions to private
object data. The difference is that there can be more than one hookData
"dynamic struct member" on a conn/result at a time, unlike errorMessage;
thus the need for an additional "lookup" value when getting hook data
(what was hookName).
A solution is to only have one function with an eventId, instead of a
register function per event. I am playing with using the name 'event'
rather than hook.
typedef enum
{
PQEVTID_INITDATA,
PQEVTID_CONNRESET,
// resultcreate, resultcopy, etc...
} PGobjectEventId;
typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
// no more key (hookName), use PGobjectEventProc address
void *PQeventData(PGconn *, PGobjectEventProc);
void *PQresultEventData(PGresult *, PGobjectEventProc);
Now there is just one libpq register function and an enum; very
resilient to future additions and ABI friendly. The API user will
follow a convention of: if you don't care about an event or don't know
what it is, just return NULL from the eventProc function (ignore it).
The implementation of a PGobjectEventProc would most likely be a switch
on the PGobjectEventId with a couple va_arg() calls (which would be very
well documented).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 living version of Postgres > >> at the time of their release, > > > I think you must have been out in the sun too long. > > Hey, he's welcome to try to do it. But it's utterly unrelated to > the patch at hand, and we are not holding up the patch at hand until > something like that happens. Nor am I suggesting holding up this patch for that reason :) Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 of their release, so 8.4's psql would be able to talk >> seamlessly to Postgres 7.4 :) > > I think you must have been out in the sun too long. One thing I really treasure about working on the Postgres project is frank feedback. :) > Just look at the pg_dump code if you want something of an idea of > what this would involve. Given that each previous version tied backslash commands to some particular chunk of SQL, what would be the problem with either immediately or lazily setting those to the chunks of SQL already present in previous versions? Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 think you must have been out in the sun too long. Hey, he's welcome to try to do it. But it's utterly unrelated to the patch at hand, and we are not holding up the patch at hand until something like that happens. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 to Postgres 7.4 :) I think you must have been out in the sun too long. Just look at the pg_dump code if you want something of an idea of what this would involve. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] extend VacAttrStats to allow stavalues of different types
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 consideration or just dropped as unimportant. Doh, this time against HEAD, not my branch ... -- Jan Urbanski GPG key ID: E583D7D2 ouden estin *** src/backend/commands/analyze.c --- src/backend/commands/analyze.c 2008-05-16 00:47:00.0 +0200 *** *** 1321,1330 arry = construct_array(stats->stavalues[k], stats->numvalues[k], ! stats->attr->atttypid, ! stats->attrtype->typlen, ! stats->attrtype->typbyval, ! stats->attrtype->typalign); values[i++] = PointerGetDatum(arry);/* stavaluesN */ } else --- 1321,1330 arry = construct_array(stats->stavalues[k], stats->numvalues[k], ! stats->statypid[k], ! stats->statyplen[k], ! stats->statypbyval[k], ! stats->statypalign[k]); values[i++] = PointerGetDatum(arry);/* stavaluesN */ } else *** *** 1854,1859 --- 1854,1867 stats->numnumbers[0] = num_mcv; stats->stavalues[0] = mcv_values; stats->numvalues[0] = num_mcv; + /* +* MCV entries have the same element type as the analyzed +* attribute. +*/ + stats->statypid[0] = stats->attr->atttypid; + stats->statyplen[0] = stats->attrtype->typlen; + stats->statypbyval[0] = stats->attrtype->typbyval; + stats->statypalign[0] = stats->attrtype->typalign; } } else if (null_cnt > 0) *** *** 2197,2202 --- 2205,2218 stats->numnumbers[slot_idx] = num_mcv; stats->stavalues[slot_idx] = mcv_values; stats->numvalues[slot_idx] = num_mcv; + /* +* MCV entries have the same element type as the analyzed +* attribute. +*/ + stats->statypid[slot_idx] = stats->attr->atttypid; + stats->statyplen[slot_idx] = stats->attrtype->typlen; + stats->statypbyval[slot_idx] = stats->attrtype->typbyval; + stats->statypalign[slot_idx] = stats->attrtype->typalign; slot_idx++; } *** *** 2281,2286 --- 2297,2310 stats->staop[slot_idx] = mystats->ltopr; stats->stavalues[slot_idx] = hist_values; stats->numvalues[slot_idx] = num_hist; + /* +* Histogram entries have the same element type as the analyzed +* attribute. +*/ + stats->statypid[slot_idx] = stats->attr->atttypid; + stats->statyplen[slot_idx] = stats->attrtype->typlen; + stats->statypbyval[slot_idx] = stats->attrtype->typbyval; + stats->statypalign[slot_idx] = stats->attrtype->typalign; slot_idx++; } *** src/include/commands/vacuum.h --- src/include/commands/vacuum.h 2008-05-16 00:47:09.0 +0200 *** *** 94,99 --- 94,119 Datum *stavalues[STATISTIC_NUM_SLOTS]; /* +* These fields describe the stavalues[n] element types. They will +* typically be the same as the column's that's underlying the slot, but +* sometimes a custom typanalyze function might want to store an array of +* something other that the analyzed column's elements. This must be filled +* in by the compute_stats routine. +
Re: [PATCHES] plpgsql CASE statement - last version
"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, b, c THEN ... by producing the equivalent of "IF x IN (a, b, c)". This means that all three of the a, b, c expressions will be evaluated even if "a" matches. The SQL spec doesn't appear to promise short-circuit evaluation in such a case, but I suspect somebody out there might have a problem someday. It didn't seem tremendously easy to fix though. I suppose anyone who does have a problem can rewrite as CASE x WHEN a THEN ... WHEN b THEN ... WHEN c THEN ... at the cost of duplicating their THEN code. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
"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 it only says "see \?" > then it's just redirecting you somewhere else, which isn't useful. Haven't been following this thread. Has the idea of making "help" just a synonym for \? not come up? Or has it been rejected? It seems simplest. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] extend VacAttrStats to allow stavalues of different types
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 just dropped as
unimportant.
Cheers,
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
*** src/backend/commands/analyze.c
--- src/backend/commands/analyze.c 2008-05-15 20:08:27.0 +0200
***
*** 1319,1350
{
ArrayType *arry;
! /*
!* XXX horrible hack - we're creating a
pg_statistic tuple for
!* a tsvector, but need to store an array of
cstrings.
!*
!* Temporary measures...
!*/
! if (stats->stakind[0] == STATISTIC_KIND_MCL)
! {
! elog(NOTICE, "severly breaking stuff by
brute force hackage");
! arry =
construct_array(stats->stavalues[k],
!
stats->numvalues[k],
!
CSTRINGOID,
!
-2, /* typlen, -2 for cstring, per
!
* comment from pg_type.h */
!
false,
!
'c');
! }
! else
! {
! arry =
construct_array(stats->stavalues[k],
!
stats->numvalues[k],
!
stats->attr->atttypid,
!
stats->attrtype->typlen,
!
stats->attrtype->typbyval,
!
stats->attrtype->typalign);
! }
values[i++] = PointerGetDatum(arry);/*
stavaluesN */
}
else
--- 1319,1330
{
ArrayType *arry;
! arry = construct_array(stats->stavalues[k],
!
stats->numvalues[k],
!
stats->statypid[k],
!
stats->statyplen[k],
!
stats->statypbyval[k],
!
stats->statypalign[k]);
values[i++] = PointerGetDatum(arry);/*
stavaluesN */
}
else
***
*** 1874,1879
--- 1854,1867
stats->numnumbers[0] = num_mcv;
stats->stavalues[0] = mcv_values;
stats->numvalues[0] = num_mcv;
+ /*
+* MCV entries have the same element type as the
analyzed
+* attribute.
+*/
+ stats->statypid[0] = stats->attr->atttypid;
+ stats->statyplen[0] = stats->attrtype->typlen;
+ stats->statypbyval[0] = stats->attrtype->typbyval;
+ stats->statypalign[0] = stats->attrtype->typalign;
}
}
else if (null_cnt > 0)
***
*** 2217,
--- 2205,2218
stats->numnumbers[slot_idx] = num_mcv;
stats->stavalues[slot_idx] = mcv_values;
stats->numvalues[slot_idx] = num_mcv;
+ /*
+* MCV entries have the same element type as the
analyzed
+* attribute.
+*/
+ stats->statypid[slot_idx] = stats->attr->atttypid;
+ stats->statyplen[slot_idx] = stats->attrtype->typlen;
+ stats->statypbyval[slot_idx] =
stats->attrtype->t
Re: [PATCHES] create or replace language
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 commands don't change the owner, so CREATE > OR REPLACE LANGUAGE shouldn't do that either. It's possible that the language owner is changed in the meantime (in pg_pltemplate). Since the owner cannot be changed from the "CREATE OR REPLACE" syntax, a modified owner in the template table is the only possibility where a new owner can came from. If "CREATE LANGUAGE" find's a language entry in pg_pltemplate, it drops any data from the commandline and uses the data from the template - so a new owner is something which should be distributed along with the REPLACE. > >> So do we want to replace any data (in my opinion only the validator is > >> left) at all or just skip any error message? > > I think you should be able to change handler and validator functions, > and the trusted flag. Or is there a reason to not allow that? Message-ID: <[EMAIL PROTECTED]> No other answer yet. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 otherwise we > would end up with a crappy UI just because a single person thinks it's > "good enough". 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 to Postgres 7.4 :) Cheers, David (well, not really bike-shedding, but trying to propose a feature that reduces the amount of UI clutter) -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 registered with a particular callback function. So you use that callback function. If it's not actually registered, you get a NULL. This is what is passed to PQaddObjectHooks, along with a conn: This is all wrong IMHO, not least because it creates ABI problems if you want to add another hook type later. Register each hook separately, eg typedef void (*PGCRHook) (PGconn *conn, void *passthrough); void PQregisterConnResetHook(PGconn *conn, PQCRHook func, void *passthrough); ... repeat for each possible hook ... regards, tom lane One can make a case to break apart the obj hooks structure into individual register functions, but I think you have a different idea in your head than what is being proposed. For starters, there is no passthru pointer to register with a callback (there could be but that is different than hook data...your register looks more like a user_ptr). The passthru pointer, what we call hookData, is allocated with a PGconn (not provided by the user). This is the point of the initHookData callback. typedef void *(*PGinitHookData)(const PGconn *conn); PQregisterInitHookData((PGconn *)NULL, (PGinitHookData)func); PQregisterConnResetHook((PGconn *)NULL, (PGCRHook)func); //etc... conn = PQconnectdb(); When connectdb returns, initHookData has already been called. So, a call to PQhookData(conn, ) will work. BUT, what is still missing from the equation is how to uniquely reference hookData on a conn. What I was previously suggesting was to use the address of initHookData, since w/o this address there wouldn't be any hook data to get. Seemed like a logical choice. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 this case at least), because otherwise we > > >would end up with a crappy UI just because a single person thinks it's > > >"good enough". > > > > > > 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 .psqlrc we can put > >\qecho "Whatever the default message is" > > or > >select "my message "+version(); > > to create the default, but then anyone with their own .psqlrc > > can re-define it to whatever they think is a "good enough" UI. > > +1 > Including no banner at all please. There is a psql quiet option that shows no banner: -q --quiet Specifies that psql should do its work quietly. By default, it prints welcome messages and various informational output. If this option is used, none of this happens. This is useful with the -c option. Within psql you can also set the QUIET variable to achieve the same effect. You could then use \echo in .psqlrc to make your own banner. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Partial match in GIN (next vesrion)
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/misc/wildspeed-0.12.tgz Changes: - Sync with CVS HEAD - add third option (StrategyNumber) for comparePartialFn. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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), because otherwise we > >would end up with a crappy UI just because a single person thinks it's > >"good enough". > > > 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 .psqlrc we can put >\qecho "Whatever the default message is" > or >select "my message "+version(); > to create the default, but then anyone with their own .psqlrc > can re-define it to whatever they think is a "good enough" UI. +1 Including no banner at all please. -- David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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) > > 8-bit characters might not work correctly. See psql > > reference > > page "Notes for Windows users" for details. > > WARNING: psql version 8.4.0, server version 8.3.1. > > Some psql features might not work. > > Type "help" for help. > > > By indenting those messages the 'help' message still stands out. > > My advice: don't do that, it just looks weird. Both of these look > fine to me: > > $ psql test > psql (8.4devel) > SSL connection (cipher: 2343, bits: 512) > Type "help" for help. > > $ psql test > psql (8.4devel) > SSL connection (cipher: 2343, bits: 512) > WARNING: Console code page (323) differs from Windows code page (2323) > 8-bit characters might not work correctly. See psql reference > page "Notes for Windows users" for details. > WARNING: psql version 8.4.0, server version 8.3.1. > Some psql features might not work. > Type "help" for help. > > Also, maybe it's just me, but I think you have put the order of these > optional things exactly backwards. I'd do > > $ psql test > psql (8.4devel) > WARNING: psql version 8.4.0, server version 8.3.1. > Some psql features might not work. > WARNING: Console code page (323) differs from Windows code page (2323) > 8-bit characters might not work correctly. See psql reference > page "Notes for Windows users" for details. > SSL connection (cipher: 2343, bits: 512) > Type "help" for help. > > Why? Well, it's just more nearly the way it used to be. OK, here is the mega-print: $ psql test psql (8.4devel, server 8.4devel) WARNING: psql version 8.4, server version 8.4. Some psql features might not work. WARNING: Console code page (44) differs from Windows code page (55) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details. SSL connection (cipher: 55, bits: 512) Type "help" for help. test=> Patch at ftp://momjian.us/pub/postgresql/mypatches/help. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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) >8-bit characters might not work correctly. See psql > reference >page "Notes for Windows users" for details. > WARNING: psql version 8.4.0, server version 8.3.1. >Some psql features might not work. > Type "help" for help. > By indenting those messages the 'help' message still stands out. My advice: don't do that, it just looks weird. Both of these look fine to me: $ psql test psql (8.4devel) SSL connection (cipher: 2343, bits: 512) Type "help" for help. $ psql test psql (8.4devel) SSL connection (cipher: 2343, bits: 512) WARNING: Console code page (323) differs from Windows code page (2323) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details. WARNING: psql version 8.4.0, server version 8.3.1. Some psql features might not work. Type "help" for help. Also, maybe it's just me, but I think you have put the order of these optional things exactly backwards. I'd do $ psql test psql (8.4devel) WARNING: psql version 8.4.0, server version 8.3.1. Some psql features might not work. WARNING: Console code page (323) differs from Windows code page (2323) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details. SSL connection (cipher: 2343, bits: 512) Type "help" for help. Why? Well, it's just more nearly the way it used to be. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 test
psql (8.4devel)
SSL connection (cipher: 2343, bits: 512)
WARNING: Console code page (323) differs from Windows code page
(2323)
8-bit characters might not work correctly. See psql
reference
page "Notes for Windows users" for details.
Type "help" for help.
test=>
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)
8-bit characters might not work correctly. See psql
reference
page "Notes for Windows users" for details.
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
Type "help" for help.
test=>
By indenting those messages the 'help' message still stands out.
Adjustments?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/help.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.127
diff -c -c -r1.127 help.c
*** src/bin/psql/help.c 14 May 2008 15:30:22 - 1.127
--- src/bin/psql/help.c 15 May 2008 19:17:27 -
***
*** 170,182
*/
fprintf(output, _("General\n"));
fprintf(output, _(" \\copyright show PostgreSQL usage and distribution terms\n"));
fprintf(output, _(" \\h [NAME] help on syntax of SQL commands, * for all commands\n"));
fprintf(output, _(" \\q quit psql\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
fprintf(output, _(" \\e [FILE] edit the query buffer (or file) with external editor\n"));
- fprintf(output, _(" \\g [FILE] send query buffer to server (and results to file or |pipe)\n"));
fprintf(output, _(" \\p show the contents of the query buffer\n"));
fprintf(output, _(" \\r reset (clear) the query buffer\n"));
#ifdef USE_READLINE
--- 170,182
*/
fprintf(output, _("General\n"));
fprintf(output, _(" \\copyright show PostgreSQL usage and distribution terms\n"));
+ fprintf(output, _(" \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
fprintf(output, _(" \\h [NAME] help on syntax of SQL commands, * for all commands\n"));
fprintf(output, _(" \\q quit psql\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
fprintf(output, _(" \\e [FILE] edit the query buffer (or file) with external editor\n"));
fprintf(output, _(" \\p show the contents of the query buffer\n"));
fprintf(output, _(" \\r reset (clear) the query buffer\n"));
#ifdef USE_READLINE
Index: src/bin/psql/mainloop.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.90
diff -c -c -r1.90 mainloop.c
*** src/bin/psql/mainloop.c 5 Apr 2008 03:40:15 - 1.90
--- src/bin/psql/mainloop.c 15 May 2008 19:17:27 -
***
*** 177,186
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_("You are using psql, the command-line interface to PostgreSQL."));
! puts(_("Enter SQL commands, or type \\? for a list of backslash options."));
! puts(_("Use \\h for SQL command help."));
! puts(_("Use \\q to quit."));
fflush(stdout);
continue;
}
--- 177,189
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_("\nYou are using psql, the command-line interface to PostgreSQL."));
! puts(_("\t\\? for psql help"));
! puts(_("\t\\h or \\help for SQL help\n"));
! puts(_("\t\\g or \";\" to execute a query"));
! puts(_("\t\\q to quit psql\n"));
! puts(_("\t\\copyright to view the copyright\n"));
!
fflush(stdout);
continue;
}
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.147
diff -c -c -r1.147 startup.c
*** src/bin/psql/startup.c 8 May 2008 17:04:26 - 1.147
--- src/bin/psql/startup.c 15 May 2008 19:17:27 -
***
*** 300,305
--- 300,312
{
int client_ver = parse_version(PG_VE
[PATCHES] SSL client configuration patch
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, it fixes a but in client revocation lists that were never looking in
the application directory.diff -u -r postgresql-8.2.7/src/interfaces/libpq/fe-connect.c postgresql-8.2.7-ssl/src/interfaces/libpq/fe-connect.c
--- postgresql-8.2.7/src/interfaces/libpq/fe-connect.c 2007-10-09 11:03:31.0 -0400
+++ postgresql-8.2.7-ssl/src/interfaces/libpq/fe-connect.c 2008-05-15 14:38:00.550668436 -0400
@@ -181,6 +181,18 @@
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
"SSL-Mode", "", 8}, /* sizeof("disable") == 8 */
+ {"sslcert", "PGSSLCERT", NULL, NULL,
+ "SSL-Client-Cert", "", 64},
+
+ {"sslkey", "PGSSLKEY", NULL, NULL,
+ "SSL-Client-Key", "", 64},
+
+ {"ssltrustcrt", "PGSSLKEY", NULL, NULL,
+ "SSL-Trusted-Keys", "", 64},
+
+ {"sslcrl", "PGSSLKEY", NULL, NULL,
+ "SSL-Revocation-List", "", 64},
+
#ifdef KRB5
/* Kerberos authentication supports specifying the service name */
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
@@ -402,7 +414,17 @@
conn->connect_timeout = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, "sslmode");
conn->sslmode = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslkey");
+ conn->sslkey = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslcert");
+ conn->sslcert = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "ssltrustcrt");
+ conn->ssltrustcrt = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslcrl");
+ conn->sslcrl = tmp ? strdup(tmp) : NULL;
+
#ifdef USE_SSL
+
tmp = conninfo_getval(connOptions, "requiressl");
if (tmp && tmp[0] == '1')
{
diff -u -r postgresql-8.2.7/src/interfaces/libpq/fe-secure.c postgresql-8.2.7-ssl/src/interfaces/libpq/fe-secure.c
--- postgresql-8.2.7/src/interfaces/libpq/fe-secure.c 2006-10-06 13:14:01.0 -0400
+++ postgresql-8.2.7-ssl/src/interfaces/libpq/fe-secure.c 2008-05-15 14:48:56.244034272 -0400
@@ -586,7 +586,10 @@
}
/* read the user certificate */
- snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
+ if(conn->sslcert)
+ strncpy(fnbuf, conn->sslcert, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
if ((fp = fopen(fnbuf, "r")) == NULL)
{
printfPQExpBuffer(&conn->errorMessage,
@@ -608,7 +611,10 @@
fclose(fp);
/* read the user key */
- snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
+ if(conn->sslcert)
+ strncpy(fnbuf, conn->sslkey, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
if (stat(fnbuf, &buf) == -1)
{
printfPQExpBuffer(&conn->errorMessage,
@@ -740,6 +746,9 @@
{
SSL_library_init();
SSL_load_error_strings();
+ ERR_load_BIO_strings ();
+ ERR_load_SSL_strings();
+ OpenSSL_add_all_algorithms ();
}
SSL_context = SSL_CTX_new(TLSv1_method());
if (!SSL_context)
@@ -778,7 +787,10 @@
/* Set up to verify server cert, if root.crt is present */
if (pqGetHomeDirectory(homedir, sizeof(homedir)))
{
- snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, ROOT_CERT_FILE);
+ if(conn->ssltrustcrt)
+ strncpy(fnbuf, conn->ssltrustcrt, sizeof(fnbuf));
+ else
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, ROOT_CERT_FILE);
if (stat(fnbuf, &buf) == 0)
{
X509_STORE *cvstore;
@@ -796,8 +808,12 @@
if ((cvstore = SSL_CTX_get_cert_store(SSL_context)) != NULL)
{
+if(conn->sslcrl)
+ strncpy(fnbuf, conn->sslcrl, sizeof(fnbuf));
+else
+ snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, ROOT_CRL_FILE);
/* setting the flags to check against the complete CRL chain */
-if (X509_STORE_load_locations(cvstore, ROOT_CRL_FILE, NULL) != 0)
+if (X509_STORE_load_locations(cvstore, fnbuf, NULL) != 0)
/* OpenSSL 0.96 does not support X509_V_FLAG_CRL_CHECK */
#ifdef X509_V_FLAG_CRL_CHECK
X509_STORE_set_flags(cvstore,
diff -u -r postgresql-8.2.7/src/interfaces/libpq/libpq-int.h postgresql-8.2.7-ssl/src/interfaces/libpq/libpq-int.h
--- postgresql-8.2.7/src/interfaces/libpq/libpq-int.h 2007-07-23 14:13:10.0 -0400
+++ postgresql-8.2.7-ssl/src/interfaces/libpq/libpq-int.h 2008-05-15 14:05:07.614237197 -0400
@@ -271,6 +271,10 @@
char *pguser; /* Postgres username and password, if any */
char *pgpass;
char *sslmode; /* SSL mode (require,prefer,allow,disable) */
+ char *sslkey; /* ssl key file filename for call back */
+ char *sslcert; /* ssl certificate filename for call back */
+ char *ssltrustcrt; /* Trusted certificuits */
+ char *sslcrl; /* certificates revoked by certificate authorities */
#ifdef KRB5
char *krbsrvname; /* Kerberos service name */
#endif
diff -u -r postgresql-8.2.
Re: [PATCHES] libpq object hooks
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 particular callback function. So you use that callback function. If it's not actually registered, you get a NULL. > This is what is passed to PQaddObjectHooks, along with a conn: This is all wrong IMHO, not least because it creates ABI problems if you want to add another hook type later. Register each hook separately, eg typedef void (*PGCRHook) (PGconn *conn, void *passthrough); void PQregisterConnResetHook(PGconn *conn, PQCRHook func, void *passthrough); ... repeat for each possible hook ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 .psqlrc we can put >> \qecho "Whatever the default message is" >> or >> select "my message "+version(); >> to create the default, but then anyone with their own .psqlrc >> can re-define it to whatever they think is a "good enough" UI. > We could do that but we still have to design the default banner. More to the point, we would then have to design API with which a custom .psqlrc could put out information about psql version, server version, SSL status, etc. It would take a lot of work to make this approach actually useful, and there isn't demand to justify it AFAIK. It's worth polishing the default behavior in any case, because that is what newbies are going to see. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 and no extra storage.
Note that if you want N fixed keys, you can just have N hook functions
(all calling a shared workhorse routine, no doubt). So your proposal
adds no functionality whatever if the usage involves a fixed number of
static handles. Now it could possibly allow a variable-at-runtime
number of handles, but I'd want to see a worked-out use case before
designing for that much complexity. In particular, it seems to me that
the problem would then shift to how do you know which handle to use for
the lookup, thus you've just introduced another layer of complexity
without buying anything.
I think the typical use case is just that you need to distinguish "your"
hook from anyone else's hooks, so the function address is plenty
sufficient.
It should also be noted that this whole problem *can* be solved without
any PQhookData at all: as long as you have hooks to get control at
creation and destruction of PGconns and PGresults, you can maintain your
own index data structure. I'm willing to grant some amount of extra
API-stuff to save users having to do that in simple cases, but I don't
think we need to try to support infinitely complex cases.
regards, tom lane
Okay. No problem over here.
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. Maybe initHookData() must be provided? If the end-user
doesn't need it they can just return NULL.
This is what is passed to PQaddObjectHooks, along with a conn:
typedef struct
{
//char *name; REMOVED
void *data;
/* Invoked when PQsetObjectHook is called. The pointer returned
* by the hook implementation is stored in the private storage of
* the PGconn, accessible via PQhookData(PGconn*). If no
* storage is needed, return NULL or set this hook to NULL.
*/
void *(*initHookData)(const PGconn *conn);
/* Invoked on PQreset and PQresetPoll */
void (*connReset)(const PGconn *conn);
/* Invoked on PQfinish. */
void (*connDestroy)(const PGconn *conn);
/* Invoked on PQgetResult, internally called by all exec funcs */
void *(*resultCreate)(const PGconn *conn, const PGresult *result);
/* Invoked on PQcopyResult */
void *(*resultCopy)(PGresult *dest, const PGresult *src);
/* Invoked when PQclear is called */
void (*resultDestroy)(const PGresult *result);
} PGobjectHooks;
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 with a crappy UI just because a single person thinks it's > > "good enough". > > > 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 .psqlrc we can put > \qecho "Whatever the default message is" > or > select "my message "+version(); > to create the default, but then anyone with their own .psqlrc > can re-define it to whatever they think is a "good enough" UI. We could do that but we still have to design the default banner. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Partial match in GIN (next vesrion)
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 any usage of that right now. I'll > add > this option. Ping? I'd like to get this patch out of the way. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 storage. Note that if you want N fixed keys, you can just have N hook functions (all calling a shared workhorse routine, no doubt). So your proposal adds no functionality whatever if the usage involves a fixed number of static handles. Now it could possibly allow a variable-at-runtime number of handles, but I'd want to see a worked-out use case before designing for that much complexity. In particular, it seems to me that the problem would then shift to how do you know which handle to use for the lookup, thus you've just introduced another layer of complexity without buying anything. I think the typical use case is just that you need to distinguish "your" hook from anyone else's hooks, so the function address is plenty sufficient. It should also be noted that this whole problem *can* be solved without any PQhookData at all: as long as you have hooks to get control at creation and destruction of PGconns and PGresults, you can maintain your own index data structure. I'm willing to grant some amount of extra API-stuff to save users having to do that in simple cases, but I don't think we need to try to support infinitely complex cases. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 don't need to. > Or else have the library return a unique handle when registering hooks, > rather than supplying a hook name. Uh, how would that solve your problem? Seems like the difficulty shifts from "how do I get the hook data" to "how do I get the key with which to get the hook data". regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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.
Or else have the library return a unique handle when registering hooks,
rather than supplying a hook name.
cheers
andrew
The problem with this is that hooks can be registered on a per-conn
basis. Is there a way to ensure the libpq returned handle would be the
unique across every registration of a given PGobjectHooks? ISTM that
the hook handle needs to be constant and unique somehow. Tom's idea
would work with the "very" small limitation of not being able to reuse
hook callbacks. I throw out an idea of using the address of a static,
which is constant and unique.
app_func(PGresult *res)
{
PQresultHookData(res, ?handle?);
}
app_func is not aware of what PGconn generated the result so it has no
idea what libpq returned handle to use.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 private state we are asking for. Well, depending on a hook name for this is broken-by-design anyway, because there is no way for two independently written libraries to be sure they don't choose conflicting hook names. So the need for a hook name has to go away. 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. regards, tom lane There can be cases to use the same callbacks, although unlikely. To completely avoid collisions, the below would work: Use the address of a static, maybe an 'int', as a hook hanlde. Provide the user with a macro that can make a hook handle. typedef void *PGhookHandle; // Declare an int and point "tokname" at it. The value doesn't // matter, its the pointer address we are interested in. #define PQ_MAKE_HOOK_HANDLE(tokname) \ static int hh__ ## tokname = 0; \ static const PGhookHandle tokname = &hh__ ## tokname As an example, here is what libpqtypes would do: // libpqtypes hooks.c PQ_MAKE_HOOK_HANDLE(pqthookhandle); Now the handle replaces the hookName. The "const char *hookName" member of the PQobjectHooks structure is changed to "const PGhookHanlde hookHandle". This allows for all the flexibility of a const char * w/o the collision issues. // these function prototypes change as well void *PQhookData(PGconn *, const PGhookHandle); void *PQresultHookData(PGresult *, const PGhookHandle); We will send in an updated patch. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 private state we are asking for. Well, depending on a hook name for this is broken-by-design anyway, because there is no way for two independently written libraries to be sure they don't choose conflicting hook names. So the need for a hook name has to go away. 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. Or else have the library return a unique handle when registering hooks, rather than supplying a hook name. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 a single person thinks it's "good enough". 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 .psqlrc we can put \qecho "Whatever the default message is" or select "my message "+version(); to create the default, but then anyone with their own .psqlrc can re-define it to whatever they think is a "good enough" UI. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 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=>
>
> I do feel that the help statement ought to be on its own line;
> the other way is going to look cluttered, particularly as soon
> as there's a version warning in there.
OK, here is the normal startup now:
$ sql test
psql (8.4.0)
Type "help" for help.
test=>
Here is a minor version mismatch:
$ sql test
psql (8.4.0, server 8.4.1)
Type "help" for help.
test=>
Here is a major version mismatch:
$ sql test
psql (8.4.0, server 8.3.1)
WARNING: psql version 8.4.0, server version 8.3.1.
Some psql features might not work.
Type "help" for help.
test=>
I have also added '\g' to the 'help' display:
test=> help
You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help
\g or ";" to execute a query
\q to quit psql
\copyright to view the copyright
test=>
I don't know how to generate an SSL message.
With the new smaller \? "General" section, I though it was worth
considering if we still want to do the help banner the same. Obviously
we do, but I wanted to explore it.
Patch attached.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/help.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.127
diff -c -c -r1.127 help.c
*** src/bin/psql/help.c 14 May 2008 15:30:22 - 1.127
--- src/bin/psql/help.c 15 May 2008 16:05:51 -
***
*** 170,182
*/
fprintf(output, _("General\n"));
fprintf(output, _(" \\copyright show PostgreSQL usage and
distribution terms\n"));
fprintf(output, _(" \\h [NAME] help on syntax of SQL commands, *
for all commands\n"));
fprintf(output, _(" \\q quit psql\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
fprintf(output, _(" \\e [FILE] edit the query buffer (or file)
with external editor\n"));
- fprintf(output, _(" \\g [FILE] send query buffer to server (and
results to file or |pipe)\n"));
fprintf(output, _(" \\p show the contents of the query
buffer\n"));
fprintf(output, _(" \\r reset (clear) the query
buffer\n"));
#ifdef USE_READLINE
--- 170,182
*/
fprintf(output, _("General\n"));
fprintf(output, _(" \\copyright show PostgreSQL usage and
distribution terms\n"));
+ fprintf(output, _(" \\g [FILE] or ; execute query (and send results to
file or |pipe)\n"));
fprintf(output, _(" \\h [NAME] help on syntax of SQL commands, *
for all commands\n"));
fprintf(output, _(" \\q quit psql\n"));
fprintf(output, "\n");
fprintf(output, _("Query Buffer\n"));
fprintf(output, _(" \\e [FILE] edit the query buffer (or file)
with external editor\n"));
fprintf(output, _(" \\p show the contents of the query
buffer\n"));
fprintf(output, _(" \\r reset (clear) the query
buffer\n"));
#ifdef USE_READLINE
Index: src/bin/psql/mainloop.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.90
diff -c -c -r1.90 mainloop.c
*** src/bin/psql/mainloop.c 5 Apr 2008 03:40:15 - 1.90
--- src/bin/psql/mainloop.c 15 May 2008 16:05:51 -
***
*** 177,186
(line[4] == '\0' || line[4] == ';' || isspace((unsigned
char) line[4])))
{
free(line);
! puts(_("You are using psql, the command-line interface
to PostgreSQL."));
! puts(_("Enter SQL commands, or type \\? for a list of
backslash options."));
! puts(_("Use \\h for SQL command help."));
! puts(_("Use \\q to quit."));
fflush(stdout);
continue;
}
--- 177,189
(line[4] =
Re: [PATCHES] libpq object hooks
"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 > are asking for. Well, depending on a hook name for this is broken-by-design anyway, because there is no way for two independently written libraries to be sure they don't choose conflicting hook names. So the need for a hook name has to go away. 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. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 it's "good enough". -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 say, "Nice try JD" or just commit the thing. > > Your patch is getting the same review any other patch would have. If > you want someone else to apply it I will stop working on it. I am not asking you to not review the patch. I am asking you to be productive in doing so. Your review of this patch is basically, "Even though there were two very long threads with several (on the greater side of several) different people contributing feedback, I think I know better". That behavior is frustrating, especially when I took an extreme amount of effort to address all concerns ahead of the actual commit fest. I wanted to make sure the patch would be easy to review and easy to commit. If I thought I was going to have to have the argument all over again, I just would have left the first submission as it was and then we could have burned all the time during commit fest only. Now Alvaro, Tom and I are all having the same discussion all over again but this time with Bruce. It makes no sense. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate signature.asc Description: PGP signature
Re: [PATCHES] Patch to change psql default banner v6
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 simple makes it not worth the effort in the first place. Welcome to UI development. There is always *far* more argument of minor matters of appearance than over anything else, in my experience. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks
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 that all the callbacks should be modified to send a void* along with the other arguments. This would eliminate the need for hookname there (getting the state inside callback functions). 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 are asking for. I'm a little bit stuck here. Is it possible to preserve the hookname outside of the context of the callback functions or is there something else I'm missing? (I'm sorry if I'm being obtuse) Eliminating the need for libpqtypes to need PQhookx functions, while possible, would make libpqtypes a lot more difficult to use and generally more awkward. merlin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 simple makes it not worth the effort in > the first place. > > 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 say, > "Nice try JD" or just commit the thing. Your patch is getting the same review any other patch would have. If you want someone else to apply it I will stop working on it. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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=> I do feel that the help statement ought to be on its own line; the other way is going to look cluttered, particularly as soon as there's a version warning in there. 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 simple makes it not worth the effort in the first place. 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 say, "Nice try JD" or just commit the thing. Joshua D. Drake regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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 $ psql test psql 8.4devel [ server version warning here, if needed ] [ line with SSL info here, if needed ] Type "help" for help. test=> I do feel that the help statement ought to be on its own line; the other way is going to look cluttered, particularly as soon as there's a version warning in there. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
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, version mismatch warning and/or SSL info? Oh, good point. Let me look at that. Thanks. You prefer: $ sql test psql (8.4devel) Type "help" for help. test=> help That looked so sparse to me. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] create or replace language
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 shouldn't do that either. So do we want to replace any data (in my opinion only the validator is left) at all or just skip any error message? I think you should be able to change handler and validator functions, and the trusted flag. Or is there a reason to not allow that? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] create or replace language
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 existing language, but not the core
> > > properties --- which might only be the handler function, though you
> > > could make a case for the validator and the trusted flag as well.
> >
> > Already thought about that: exchanging the handler function or the
> > libbrary might only be useful in a developing environment, i don't see
> > other use cases here. The same is true for the validator (but a missing
> > validator could be added afterwards) and in my opinion i would prefer
> > not to change the trust flag - some functions may depend on this.
> >
> > The name cannot be changed at all so only the owner and maybe the
> > validator is left ...
>
> Even the owner does not make sense, because it seems it is not possible
> that the owner will changed through the SQL interface. ALTER LANGUAGE
> already exists for this purpose and CREATE LANGUAGE has no option for
> the language owner.
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).
> So do we want to replace any data (in my opinion only the validator is
> left) at all or just skip any error message?
Anyone has an opinion here?
Kind regards
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
diff -x CVS -ruN pgsql.orig/src/backend/commands/proclang.c pgsql/src/backend/commands/proclang.c
--- pgsql.orig/src/backend/commands/proclang.c 2008-04-29 23:59:02.0 +0200
+++ pgsql/src/backend/commands/proclang.c 2008-05-15 12:18:39.0 +0200
@@ -48,7 +48,7 @@
} PLTemplate;
static void create_proc_lang(const char *languageName,
- Oid languageOwner, Oid handlerOid, Oid valOid, bool trusted);
+ Oid languageOwner, Oid handlerOid, Oid valOid, bool trusted, int replace);
static PLTemplate *find_language_template(const char *languageName);
static void AlterLanguageOwner_internal(HeapTuple tup, Relation rel,
Oid newOwnerId);
@@ -67,6 +67,7 @@
valOid;
Oid funcrettype;
Oid funcargtypes[1];
+ int replace; /* store info about replace */
/*
* Translate the language name and check that this language doesn't
@@ -74,12 +75,26 @@
*/
languageName = case_translate_language_name(stmt->plname);
+
+ replace = 0;
if (SearchSysCacheExists(LANGNAME,
PointerGetDatum(languageName),
0, 0, 0))
- ereport(ERROR,
-(errcode(ERRCODE_DUPLICATE_OBJECT),
- errmsg("language \"%s\" already exists", languageName)));
+ {
+ if (stmt->replace)
+ {
+ /* if the language exist but "OR REPLACE" is given, we just remember
+ * the fact here */
+ replace = 1;
+ }
+ else
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_OBJECT),
+ errmsg("language \"%s\" already exists", languageName)));
+ }
+ }
+
/*
* If we have template information for the language, ignore the supplied
@@ -131,7 +146,7 @@
{
handlerOid = ProcedureCreate(pltemplate->tmplhandler,
PG_CATALOG_NAMESPACE,
- false, /* replace */
+ stmt->replace, /* replace */
false, /* returnsSet */
LANGUAGE_HANDLEROID,
ClanguageId,
@@ -164,7 +179,7 @@
{
valOid = ProcedureCreate(pltemplate->tmplvalidator,
PG_CATALOG_NAMESPACE,
- false, /* replace */
+ stmt->replace, /* replace */
false, /* returnsSet */
VOIDOID,
ClanguageId,
@@ -189,7 +204,7 @@
/* ok, create it */
create_proc_lang(languageName, GetUserId(), handlerOid, valOid,
- pltemplate->tmpltrusted);
+ pltemplate->tmpltrusted, replace);
}
else
{
@@ -253,7 +268,7 @@
/* ok, create it */
create_proc_lang(languageName, GetUserId(), handlerOid, valOid,
- stmt->pltrusted);
+ stmt->pltrusted, replace);
}
}
@@ -262,7 +277,7 @@
*/
static void
create_proc_lang(const char *languageName,
- Oid languageOwner, Oid handlerOid, Oid valOid, bool trusted)
+ Oid languageOwner, Oid handlerOid, Oid valOid, bool trusted, int replace)
{
Relation rel;
TupleDesc tupDesc;
@@ -273,56 +288,83 @@
ObjectAddress myself,
referenced;
- /*
- * Insert the new language into pg_language
- */
- rel = heap_open(LanguageRelationId, RowExclusiveLock);
- tupDesc = rel->rd_att;
+ if (replace == 0)
+ {
+ /*
+ * Insert the new language into pg_language
+ */
+ rel = heap_open(LanguageRelationId, RowExclusiveLock);
+ tupDesc = rel->rd_att;
- memset(values, 0, sizeof(values));
- memset(nulls, ' ', sizeof(nulls));
+ memset(values, 0, sizeof(values));
+ memset(nulls, ' ', sizeof(nulls));
- namestrcpy(&langname, languageName);
- values[Anum_pg_lan
Re: [PATCHES] Patch to change psql default banner v6
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 warning and/or SSL info? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
