Assign the fixed user id 1 to the user created by initdb.
A stand-alone backend will always set the user id to 1.
(Consequently, the name of that user is no longer important.)
In stand-alone mode, the user id 1 will have implicit superuser
status, to allow repairs even if there are no users defined.
Print a warning message when starting in stand-alone mode when no
users are defined.
Disallow dropping the current user and session user.
Granting/revoking superuser status also grants/revokes usecatupd.
(Previously, it would never grant it back. This could lead to "deadlocks".)
CREATE USER and CREATE GROUP will start allocating user ids at 100
(unless explicitly specified), to prevent accidental creation of a
superuser (plus some room for future extensions).
> > ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
> > you change it? It's one line change. Again thanks.
Forget it! A default client encoding must be set by actual database encoding...
Please apply the small attached patch that solve it better.
Karel Zak
We will no longer try to send elog messages to the client before we have
initialized backend libpq (oops); however, reporting bogus commandline
switches via elog does work now (not irrelevant, because of PGOPTIONS).
Fix problem with inappropriate sending of checkpoint-process messages
to stderr.
suite. This reduces the number of failures from 9 to 7.
Both ConnectionTest and JBuilderTest did not create their own
tables, which caused these test cases to fail with "relation ...
does not exist". It appears these test cases relied on tables
created by the example code elsewhere in the source tree. I've
added the necessary "create table" and "drop table" statements
to the test cases, using the column definitions from the example
code.
While working on that I modified the helper method createTable
in JDBC2Tests.java to take a table parameter, rather than using
table names passed via the properties in build.xml. I'm not sure
what that was good for, and in fact, except for the default
table name "jdbctest", this functionality wasn't used at all.
Ren? Pijlman
discussion on pgsql-hackers (especially the frightening memory dump in
<12273.999562219@sss.pgh.pa.us>), we decided that it is best not to
use identifiers from an untrusted source at all. Therefore, all
claims of the suitability of PQescapeString() for identifiers have
been removed.
Florian Weimer
table creation time. Big deal you say - but this patch is the basis of the
next thing which is adding PRIMARY KEYs after table creation time. (Which
is currently impossible without twiddling catalogs)
Rundown
-------
* I have made the makeObjectName function of analyze.c non-static, and
exported it in analyze.h
* I have included analyze.h and defrem.h into command.c, to support
makingObjectNames and creating indices
* I removed the 'case CONSTR_PRIMARY' clause so that it properly fails and
says you can't add primary keys, rather than just doing nothing and
reporting nothing!!!
* I have modified the docs.
Algorithm
---------
* If name specified is null, search for a new valid constraint name. I'm
not sure if I should "lock" my generated name somehow tho - should I open
the relation before doing this step?
* Open relation in access exclusive mode
* Check that the constraint does not already exist
* Define the new index
* Warn if they're doubling up on an existing index
Christopher Kings-Lynne
>tcl-extension for postgreSQL.
>I'm currently using 7.0 and always getting a seg fault when I try to
>read from the database connection after issueing a "COPY table TO
>stdout;" (I'm using the connection handle, *not* the result handle).
>Maybe this is fixed in a later release.
>The README file in src/interfaces/libpgtcl tells me, that this should
>work, but unforunately it doesn't.
Yes, it seems broken. It is a bug in libpgtcl. Are you running Tcl >= 8.3.2?
That's when the Tcl team changed the data structure for channel
callbacks. The change itself was designed to be backward compatible, but I
suspect a related change made the code more sensitive to errors in the
structure (NULL pointers where functions are required). Either that, or
nobody has tried to use libpgtcl with COPY in a long time.
First, I have to say I can't think of a good reason to use PostgreSQL's
COPY command from a Tcl application. I think it should only be used with
psql for importing data from another source into PostgreSQL, or for
exporting PostgreSQL data into another database (but why would anyone do
that?) If it was me, I would stick with SELECT and INSERT and be "SQL
Compliant".
OK, editorial is over. Try applying the patch below to fix
src/interfaces/libpgtcl/pgtclId.c
and let us know if it works. I did little testing on it, but my test did
segfault before and ran fine (copy in and copy out) after the patch. This
is for PostgreSQL-7.1.2 - since you are running older 7.0, I don't know if
this will work, but I suspect it will.
PS It's the absence of PgWatchProc which kills it. I didn't upgrade it
to the "V2" channel type structure, so it should be compatible with older
Tcl's. But aside from gets and puts, I doubt any other file operations
would work on the handle during a copy.
ljb
occur unconditionally, even if the rule should otherwise execute
conditionally. This is more useful than giving an error, even though it's
not truly the correct behavior. Per today's pghackers discussion.
for them, and making them just wastes time during backend startup/shutdown.
Also, remove compile-time MAXBACKENDS limit per long-ago proposal.
You can now set MaxBackends as high as your kernel can stand without
any reconfiguration/recompilation.
>
>> On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
>> public boolean isWritable(int column) throws SQLException
>> {
>> return !isReadOnly(column);
>> }
Actually, I think this change has a consequence for this method
in the same class:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return isWritable(column);
}
This is from the JDBC spec
(http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSetMetaData.html):
isReadOnly() - Indicates whether the designated column is
definitely not writable.
isWritable() - Indicates whether it is possible for a write on
the designated column to succeed.
isDefinitelyWritable() - Indicates whether a write on the
designated column will definitely succeed.
At this time we don't really implement the fine semantics of
these methods. I would suggest the following defaults:
isReadOnly() false
isWritable() true
isDefinitelyWritable() false
And that would mean that your patch is correct, but
isDefinitelyWritable() would need to be patched accordingly:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return false;
}
Again, both in jdbc1 and jdbc2.
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
>public boolean isWritable(int column) throws SQLException
>{
> if (isReadOnly(column))
> return true;
> else
> return false;
>}
The author probably intended:
public boolean isWritable(int column) throws SQLException
{
return !isReadOnly(column);
}
And if he would have coded it this way he wouldn't have made
this mistake :-)
>hence, isWritable() will always return false. this is something
>of a problem :)
Why exactly? In a way, true is just as incorrect as false, and
perhaps it should throw "not implemented". But I guess that
would be too non-backwardly-compatible.
>let me know if i can provide further information.
Will you submit a patch?
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
-------------------------------------------------------------------
Subject: Re: [PATCHES] encoding names
From: Karel Zak <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Date: Fri, 31 Aug 2001 17:24:38 +0200
On Thu, Aug 30, 2001 at 01:30:40AM +0200, Peter Eisentraut wrote:
> > - convert encoding 'name' to 'id'
>
> I thought we decided not to add functions returning "new" names until we
> know exactly what the new names should be, and pending schema
Ok, the patch not to add functions.
> better
>
> ...(): encoding name too long
Fixed.
I found new bug in command/variable.c in parse_client_encoding(), nobody
probably never see this error:
if (pg_set_client_encoding(encoding))
{
elog(ERROR, "Conversion between %s and %s is not supported",
value, GetDatabaseEncodingName());
}
because pg_set_client_encoding() returns -1 for error and 0 as true.
It's fixed too.
IMHO it can be apply.
Karel
PS:
* following files are renamed:
src/utils/mb/Unicode/KOI8_to_utf8.map -->
src/utils/mb/Unicode/koi8r_to_utf8.map
src/utils/mb/Unicode/WIN_to_utf8.map -->
src/utils/mb/Unicode/win1251_to_utf8.map
src/utils/mb/Unicode/utf8_to_KOI8.map -->
src/utils/mb/Unicode/utf8_to_koi8r.map
src/utils/mb/Unicode/utf8_to_WIN.map -->
src/utils/mb/Unicode/utf8_to_win1251.map
* new file:
src/utils/mb/encname.c
* removed file:
src/utils/mb/common.c
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
> pam_strerror() should be used a few more times, rather than just saying
> "Error!". Also, the configure.in snippet seems wrong. You add
> -I$pam_prefix/include/security to $INCLUDES and then you #include
> <security/pam_appl.h>. This whole thing is probably unnecessary, since
> PAM is a system library on the systems where it exists, so the headers
> and libraries are found automatically, unlike OpenSSL and
> Kerberos.
See attached revised patch. (I'm sure the configure.in stuff can be done
right/better, I'm just not enough of a autoconf guru to know what to
change it to.)
Dominic J. Eidson
- new millisecond (ms) and microsecond (us) support
- more robus parsing from string - used is separator checking for
non-exact formats like to_date('2001-9-1', 'YYYY-MM-DD')
- SGML docs are included
Karel Zak
flawed in the following ways:
1. Only returned columns that had a default value defined, rather than all
columns in a table
2. Used 2 * N + 1 queries to find out attributes, comments and typenames
for N columns.
By using some outer join syntax it is possible to retrieve all necessary
information in just one SQL statement. This means this version is only
suitable for PostgreSQL >= 7.1. Don't know whether that's a problem.
I've tested this function with current sources and 7.1.3 and patched both
jdbc1 and jdbc2. I haven't compiled nor tested the jdbc1 version though, as
I have no JDK 1.1 available.
Note the discussion in http://fts.postgresql.org/db/mw/msg.html?mid=1029626
regarding differences in obtaining comments on database object in 7.1 and
7.2. I was unable to use the following syntax (or similar ones):
select
...,
description
from
...
left outer join col_description(a.attrelid, a.attnum) description
order by
c.relname, a.attnum;
(the error was parse error at or near '(') so I had to paste the actual
code for the col_description function into the left outer join. Maybe
someone who is more knowledgable about outer joins might provide me with a
better SQL statement.
Jeroen van Vianen
includes windows.h, which #defines ERROR to 0. PostgreSQL's logging functions
define ERROR to -1. This patch redefines ERROR to -1 to avoid current or
future breakage of the logging functions.
Gerhard H?ring
> > -patches as well.
>
> The -Bdynamic probably ought to disappear.
That was there already, but I have no objections. I was trying to
make minimal changes.
Larry Rosenman
