> I can't get SSL connections to work at all with the latest checkout
> from CVS HEAD. The culprit appears to be a typo as seen in patch
> below.
*blush* This is indeed a type-o in the patch I submitted, could
someone apply the below patch from Jon?
Pointy hat to: seanc
-sc
> Index: backend/lib
Quoting Tom Lane <[EMAIL PROTECTED]>:
> > Should options not for general use (e.g., session_auth_is_superuser)
> > be hidden from this tool? Are they? What other provisions of this
> > kind does this tool make?
>
> The original intent of the standalone tool was to display stuff that
> could use
Folks,
At long last I put together a patch to support 4 client SSL negotiation
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <[EMAIL PROTECTED]> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-ha
PostgreSQL folks,
I can't get SSL connections to work at all with the latest checkout from
CVS HEAD. The culprit appears to be a typo as seen in patch below.
Jon
Index: backend/libpq/be-secure.c
===
RCS file: /projects/cvsroot/pgs
Joe Conway <[EMAIL PROTECTED]> writes:
> One note; this change
>> ! get_fn_expr_rettype(FunctionCallInfo fcinfo)
>> to
>> ! get_fn_expr_rettype(FmgrInfo *flinfo)
> is a good example why some things, particularly PLs, are better off
> being in the main source tree rather than on gborg (or someplac
Tom Lane wrote:
What I've done instead is not to weaken type checking, but simply to
postpone all checking of the body of a SQL function to runtime if it
has any polymorphic arguments. At runtime, we know the actual types
for the arguments, and we know the actual assigned result type, and
then we
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If the option is named --long-help, I'd expect a longer version of
> --help, which this is not. The name should probably involve "help"
> and "config" to make it clearer what you get. (Personally, I think
> "help" should go before the qualifying word
Joe Conway <[EMAIL PROTECTED]> writes:
> Attached is a patch that implements polymorphic aggregates.
> Included in the patch, I changed SQL language functions so that they
> could be declared with and use polymorphic types.
I've committed the polymorphic-SQL-functions part of this separately.
I
Dennis Björklund writes:
> Here is another update of the swedish translation. I sent one a couple of
> months ago but it never was commited (and therefor not tested by anybody
> but me).
Installed.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)--
Aizaz Ahmed writes:
> The attached patch adds the --long-help option to the server executable.
Conceptual comments:
If the option is named --long-help, I'd expect a longer version of
--help, which this is not. The name should probably involve "help"
and "config" to make it clearer what you get.
Josh Berkus writes:
> initdb.patch, written by Shridhar, patches initdb so that the LC_*
> localization variables are inserted into postgresql.conf at the point
> commented "#LC VARS GO HERE!"
It's pretty pointless to use
cat $file | sed 's/.../'
because sed can open files perfectly well:
sed
[EMAIL PROTECTED] writes:
> ! /* A year and a day is currently an error, as -DD-MM is not allowed */
> ! else if ((fmask & DTK_M(YEAR)) && (fmask & DTK_M(MONTH)))
> ! return -1;
I believe this conditional is incorrect. The second part should be
DTK_M(DAY).
--
Peter Eise
Joe Conway <[EMAIL PROTECTED]> writes:
> With the current linked list, the function is effectively leaked to the
> end of the session anyway, so I don't think this is any worse. Thoughts?
Don't worry about it now. If a plpgsql function cache entry is
discarded, we leak far more than just the fun
Tom Lane wrote:
Thinking about this further, it occurs to me that there's no hard reason
plpgsql (and other PLs that adopt the we-can-convert-anything-to-string
philosophy, such as pltcl) couldn't allow arguments (though not results)
of type ANY. It's not different from accepting ANYELEMENT as far
Joe Conway wrote:
Compiles clean, and passes all regression tests. I'll look to update the
docs and regression tests as part of my post freeze array/polymorphic
function cleanup.
Oh, almost forgot. I had one question, seen here in
get_function_by_signature()
+ if (!entry_valid)
+ {
+ plp
Tom Lane wrote:
> Joe Conway wrote:
2) create hash key using a new structure that includes function oid,
return type, and argument types, and use that for direct lookup.
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, since
Joe Conway <[EMAIL PROTECTED]> writes:
> Do I have until midnite PDT, or EDT?
We hadn't actually set a formal deadline time AFAIR. Midnight your
local time is fine with me.
Thinking about this further, it occurs to me that there's no hard reason
plpgsql (and other PLs that adopt the we-can-conve
Patch applied,
thanks,
dave
On Thu, 2003-06-19 at 16:51, Kim Ho wrote:
> Problem:
> - Boolean not on list of SQLKeywords (The JDBC CTS seems to think that
> it should be)
> - setObject(x,y,Types.INTEGER) will throw exceptions if y is a Boolean.
>
> Fix:
> - Added Boolean to Keywords list.
>
Tom Lane wrote:
If only ANYELEMENT and not ANYARRAY appears in a function declaration,
then it can stand for any type, because only rule 2 applies. (The
difference from ANY is that multiple occurences of ANYELEMENT are all
constrained to stand for the same type.)
Hmmm, I don't remember that nuance
Joe Conway <[EMAIL PROTECTED]> writes:
> Are you referring to ANYELEMENT actually being an array at runtime?
> That's the first time I've heard that concept.
That was the behavior we agreed to some time ago, to avoid needing
to entangle ANY into the polymorphism logic. See the comments for
check
The attached patch adds the --long-help option to the server executable.
This option displays all the available runtime options for that
particular server version, along with Max, Min and Reset values if
applicable and a description. It also groups the runtime options
together in accordance with t
Tom Lane wrote:
In the second case (where you know actual argument type at a different
position) you must know whether the other position's declared type is
anyarray or anyelement, and you can't assume it's the same as the one at
the position you want to resolve.
I still don't understand why that's
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You're not providing enough info to resolve_type to let it handle all
>> four cases correctly.
> No, resolve_type() is not at all specific to polymorphic aggregates. It
> implements the rules of polymorphism that we previously agreed to,
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
+ * The rules for this resolution are as follows:
+ * 1) if the context type is polymorphic, punt and return type_to_resolve
+ *unchanged
+ * 2) if type_to_resolve is ANYARRAY (polymorphic), then return context_type
+ *if it is al
Joe Conway <[EMAIL PROTECTED]> writes:
+ * The rules for this resolution are as follows:
+ * 1) if the context type is polymorphic, punt and return type_to_resolve
+ *unchanged
+ * 2) if type_to_resolve is ANYARRAY (polymorphic), then return context_type
+ *if it is already an array t
Tom Lane wrote:
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, since it might produce
better-distributed hash values.)
OK -- I figured that's what you'd say, so I've already started down that
road.
dynahash only supports f
> Do you think it would be better to do
> 1) a hash lookup by function oid to a linked list of different compiled
> versions (for each set of argument/return types)
>-or-
> 2) create hash key using a new structure that includes function oid,
> return type, and argument types, and use that fo
Joe Conway wrote:
Tom Lane wrote:
(It might be time to change the cache lookup into a hashtable instead of
a simple linear list search...)
I could do that if you want, but do you really think it's worth it? How
long does a linked list have to get before a hash table starts to be a
win (this is s
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Another tack is to change the section title to something more
>> inclusive. Maybe "Error Reporting and Logging"?
> Sounds good to me. Shall we apply the patch I just submitted, and then I'll
> submit a patch for both runtime.sgml and postgresql.conf.sa
Tom,
> Another tack is to change the section title to something more
> inclusive. Maybe "Error Reporting and Logging"?
Sounds good to me. Shall we apply the patch I just submitted, and then I'll
submit a patch for both runtime.sgml and postgresql.conf.sample?
--
-Josh Berkus
__AGLIO DAT
As per the suggestions received, the syntax for the DATACUBE has
been modified to
SELECT
INTO
FROM
WHERE
GROUP BY CUBE
HAVING ;
Kindly note that the file datacube.c should be placed in src/backend/tcop/
and datacube.h should be in src/include.
Please let us know
> So, I should put it under "Client Connection Defaults", then?
Probably. But then you have to figure out what to do with the list of
values that it shares with server_min_messages.
Another tack is to change the section title to something more
inclusive. Maybe "Error Reporting and Logging"?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Here is another attempt at the datetime fix, to stop the ambiguity
for dates like "01-13-2003". I put the > 12 month validation in because
otherwise it is still read in as a "month", but it rol
Tom,
> > What is CLIENT_MIN_MESSAGES for, then?
>
> Controls which messages get sent to the client.
So, I should put it under "Client Connection Defaults", then?
--
-Josh Berkus
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Co
Josh Berkus <[EMAIL PROTECTED]> writes:
> What is CLIENT_MIN_MESSAGES for, then?
Controls which messages get sent to the client.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
Tom,
> BTW, now that I look more closely at the new docs, there are some
> classifications that seem pretty bizarre. For instance,
> CLIENT_MIN_MESSAGES has nothing to do with the server log and doesn't
> seem to belong in a section about logging ...
Would have been nice if someone had mentioned
Josh Berkus <[EMAIL PROTECTED]> writes:
> postgresql.conf.patch re-orders postgresql.conf.sample according to the ord=
> er=20
> patched into runtime.sgml last week.
I've probably already broken this patch by modifying .conf.sample :-(.
Will take care of the cleanup.
BTW, now that I look more clo
sumit <[EMAIL PROTECTED]> writes:
> Thanks for letting know. Could you also let me know the exact
> syntax, I mean, we are not sure whether GROUP BY CUBE(...) is followed by
> a HAVING clause.
Better look at the SQL99 spec for yourself. There's a link to a draft
version in our developer's
Oops. Forgot to attach it last time.
On Mon, 2003-06-30 at 12:44, Barry Lind wrote:
> Kim,
>
> Are you going to be submitting a patch for this?
>
> thanks,
> --Barry
>
>
> Kim Ho wrote:
> > On Wed, 2003-06-18 at 13:09, Kim Ho wrote:
> >
> >>Problem:
> >> - setObject(x,y,Types.BIT) throws an
Kim,
Are you going to be submitting a patch for this?
thanks,
--Barry
Kim Ho wrote:
On Wed, 2003-06-18 at 13:09, Kim Ho wrote:
Problem:
- setObject(x,y,Types.BIT) throws an exception if y is a Number
- getObject() on a bit column will return null instead of True or False
Boolean objects
Added Pr
Patch applied.
thanks,
--Barry
Kris Jurka wrote:
On Sat, 28 Jun 2003, Kurt Roeckx wrote:
On Thu, Jun 26, 2003 at 08:02:01AM -0400, Kris Jurka wrote:
On Thu, 26 Jun 2003, Manuel Gil [iso-8859-1] P?rez wrote:
Hi all.
I have a Java application that it connects to the PostgreSQL database with
IP
Patch applied.
--Barry
Kim Ho wrote:
Problem:
- If you try to setMaxRows(), setQueryTimeout() or setFetchSize()
to negative values, it should throw an exception, but doesn't. JDBC CTS
test failures.
Fix:
- Added new error messages to errors.properties file.
- PSQLExceptions thrown when user a
Folks,
Attached are 2 patches:
postgresql.conf.patch re-orders postgresql.conf.sample according to the order
patched into runtime.sgml last week.
initdb.patch, written by Shridhar, patches initdb so that the LC_*
localization variables are inserted into postgresql.conf at the point
commented
Thanks for letting know. Could you also let me know the exact
syntax, I mean, we are not sure whether GROUP BY CUBE(...) is followed by
a HAVING clause. Kindly inform us soon so that we can make the changes and
send you the updated patch and files.
Sumit
On Mon, 30 Jun 2003, Tom Lane
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
The attached patch enables PL/pgSQL functions (but not triggers) to
accept and return polymorphic types. It is careful to return false from
func_up_to_date() if any of the polymorphic types change from
call-to-call.
I don't think you can use
sumit <[EMAIL PROTECTED]> writes:
> In keeping with this, we first define the syntax of a CUBE statement as follows:
> SELECT
> INTO
> FROM
> WHERE
> GROUP BY
> HAVING
> WITH CUBE;
SQL99 defines a GROUP BY CUBE(...) operation, which seems to do the same
thing as this. Why are you using a n
Joe Conway <[EMAIL PROTECTED]> writes:
> The attached patch enables PL/pgSQL functions (but not triggers) to
> accept and return polymorphic types. It is careful to return false from
> func_up_to_date() if any of the polymorphic types change from
> call-to-call.
I don't think you can usefully d
Well, it is true that the information for the ALL rows is present
in the base query. But then adding the ALL rows directly after examining
the result, we think, is not as efficient as it sounds.
Consider the situation you are talking about. Suppose we decide to
add the ALL rows
Here is another update of the swedish translation. I sent one a couple of
months ago but it never was commited (and therefor not tested by anybody
but me).
--
/Dennis
psql-sv.po.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP
I'm curious to know why you implement this as a union of queries, since,
unless my understanding is badly awry, you have all the information
necessary for the ALL rows by running the base (ie. without cube) query, Why
not just run that query and then add the ALL rows from examining the
results? IS
Hi!
We have added the CUBE operator for PostgreSQL. Please find the
attached patch.
Another thing to note is that the file datacube.c should
be placed in src/backend/tcop/ and datacube.h should be in src/include.
The syntax of the query is
SELECT
INTO
FROM
WHERE
GROUP B
51 matches
Mail list logo
