Tom Lane [Thu, 18 Oct 2001 16:11:42 +0000 (16:11 +0000)]
Extend code that deduces implied equality clauses to detect whether a
clause being added to a particular restriction-clause list is redundant
with those already in the list. This avoids useless work at runtime,
and (perhaps more importantly) keeps the selectivity estimation routines
from generating too-small estimates of numbers of output rows.
Also some minor improvements in OPTIMIZER_DEBUG displays.
Bruce Momjian [Tue, 16 Oct 2001 13:42:57 +0000 (13:42 +0000)]
Python handle as string all int8 values from postgresql. This could be
view when using the aggregate function count() and function nextval
that returns an int8 value, but in python is represented like string:
Tatsuo Ishii [Tue, 16 Oct 2001 10:09:17 +0000 (10:09 +0000)]
Ok, here is the modified encoding table (column1 is the standard name,
2 is our "official" name, and 3 is alias). If there's no objection, I
will change them.
Bruce Momjian [Mon, 15 Oct 2001 18:16:31 +0000 (18:16 +0000)]
> Uh, isn't the correct fix
> ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> make_str("to"), $7, $8);
> ISTM your patch loses the opt_with_grant clause. (Of course the
> backend doesn't currently accept that clause anyway, but that's no
> reason for ecpg to drop it.)
My patch doesn't loose the option, it's never been passed on anyway:
opt_with_grant: WITH GRANT OPTION
{
mmerror(ET_ERROR, "WITH GRANT OPTION is not supported. Only relation owners can
set privileges");
}
| /*EMPTY*/
;
The existing code in ecpg/preproc/preproc.y to handle the WITH option
simply throws an error and aborts the processing... The patch below
prevents the segfault and also passes on the WITH option to the
backend, probably a better fix.
Tatsuo Ishii [Mon, 15 Oct 2001 01:25:10 +0000 (01:25 +0000)]
Commit Patrice's patches except:
> - corrects a bit the UTF-8 code from Tatsuo to allow Unicode 3.1
> characters (characters with values >= 0x10000, which are encoded on
> four bytes).
Also, update mb/expected/unicode.out. This is necessary since the
patches affetc the result of queries using UTF-8.
---------------------------------------------------------------
Hi,
I should have sent the patch earlier, but got delayed by other stuff.
Anyway, here is the patch:
- most of the functionality is only activated when MULTIBYTE is
defined,
- check valid UTF-8 characters, client-side only yet, and only on
output, you still can send invalid UTF-8 to the server (so, it's
only partly compliant to Unicode 3.1, but that's better than
nothing).
- formats with the correct number of columns (that's why I made it in
the first place after all), but only for UNICODE. However, the code
allows to plug-in routines for other encodings, as Tatsuo did for
the other multibyte functions.
- corrects a bit the UTF-8 code from Tatsuo to allow Unicode 3.1
characters (characters with values >= 0x10000, which are encoded on
four bytes).
- doesn't depend on the locale capabilities of the glibc (useful for
remote telnet).
I would like somebody to check it closely, as it is my first patch to
pgsql. Also, I created dummy .orig files, so that the two files I
created are included, I hope that's the right way.
Now, a lot of functionality is NOT included here, but I will keep that
for 7.3 :) That includes all string checking on the server side (which
will have to be a bit more optimised ;) ), and the input checking on
the client side for UTF-8, though that should not be difficult. It's
just to send the strings through mbvalidate() before sending them to
the server. Strong checking on UTF-8 strings is mandatory to be
compliant with Unicode 3.1+ .
Do I have time to look for a patch to include iso-8859-15 for 7.2 ?
The euro is coming 1. january 2002 (before 7.3 !) and over 280
millions people in Europe will need the euro sign and only iso-8859-15
and iso-8859-16 have it (and unfortunately, I don't think all Unices
will switch to Unicode in the meantime)....
err... yes, I know that this is not every single person in Europe that
uses PostgreSql, so it's not exactly 280m, but it's just a matter of
time ! ;)
I'll come back (on pgsql-hackers) later to ask a few questions
regarding the full unicode support (normalisation, collation,
regexes,...) on the server side :)
Here is the patch !
Patrice.
--
Patrice HÉDÉ ------------------------------- patrice à islande org -----
-- Isn't it weird how scientists can imagine all the matter of the
universe exploding out of a dot smaller than the head of a pin, but they
can't come up with a more evocative name for it than "The Big Bang" ?
-- What would _you_ call the creation of the universe ?
-- "The HORRENDOUS SPACE KABLOOIE !" - Calvin and Hobbes
------------------------------------------ http://www.islande.org/ -----
Tom Lane [Sat, 13 Oct 2001 23:32:34 +0000 (23:32 +0000)]
Make selectivity routines cope gracefully with NaNs, infinities, and
NUMERIC values that are out of the range of 'double'. Per trouble
report from Mike Quinn.
Tom Lane [Sat, 13 Oct 2001 17:40:24 +0000 (17:40 +0000)]
path_inter, path_distance, path_length, dist_ppath now do the right
things with closed paths --- ie, include the closing line segment in
their calculations. Per bug report from Curtis Barrett 9-Oct-01.
Bruce Momjian [Sat, 13 Oct 2001 04:23:50 +0000 (04:23 +0000)]
Attached patch for unconditional enabling of pltcl-unknown support.
Enabling this feature adds very light overhead of 1 select from pg_class on
first using of pl/tcl in backend if unknown suppport is really unused.
But pl/tcl with this support has very improved functionality.
Tatsuo Ishii [Fri, 12 Oct 2001 02:08:34 +0000 (02:08 +0000)]
Add a new function "pg_client_encoding" which returns the current client
side encoding name. This is necessary for client API's such as JDBC
to perform correct encoding conversions. See my email "[HACKERS]
pg_client_encoding" 10 Sep 2001.
Tom Lane [Fri, 12 Oct 2001 00:07:15 +0000 (00:07 +0000)]
Break transformCreateStmt() into multiple routines and make
transformAlterStmt() use these routines, instead of having lots of
duplicate (not to mention should-have-been-duplicate) code.
Adding a column with a CHECK constraint actually works now,
and the tests to reject unsupported DEFAULT and NOT NULL clauses
actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo
having to have created the column(s) NOT NULL already.
Bruce Momjian [Thu, 11 Oct 2001 16:54:18 +0000 (16:54 +0000)]
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> As you can see, psql reconnect as any user if the password is same as
> foo. Of course this is due to the careless password setting, but I
> think it's better to prompt ANY TIME the user tries to switch to
> another user. Comments?
Yeah, I agree. Looks like a simple change in dbconnect():
/*
* Use old password if no new one given (if you didn't have an old
* one, fine)
*/
if (!pwparam && oldconn)
pwparam = PQpass(oldconn);
to
/*
* Use old password (if any) if no new one given and we are
* reconnecting as same user
*/
if (!pwparam && oldconn && PQuser(oldconn) && userparam &&
strcmp(PQuser(oldconn), userparam) == 0)
pwparam = PQpass(oldconn);
Barry Lind [Tue, 9 Oct 2001 20:47:35 +0000 (20:47 +0000)]
This patch fixes a bug introduced in the jdbc bytea support patch.
That patch broke the ability to read data from binary cursors.
--Barry Lind
Modified Files:
pgsql/src/interfaces/jdbc/org/postgresql/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/UpdateableResultSet.java
Bunch of copy fitting and style sheet tweakage to get decent looking print
output (from pdfjadetex). Also updated instructions to install documentation
processing toolchain.
Tom Lane [Tue, 9 Oct 2001 15:59:56 +0000 (15:59 +0000)]
Change plpgsql compiler so that all elogs are trapped and a suitable
NOTICE added about error location (same method already used by plpgsql
executor). Add checking of pg_proc row xmin/cmin to ensure that
plpgsql functions will be recompiled after they've been modified by
CREATE OR REPLACE FUNCTION.
Tom Lane [Tue, 9 Oct 2001 04:15:38 +0000 (04:15 +0000)]
Change plpgsql to depend on main parser's type-declaration grammar,
rather than having its own somewhat half-baked notion of what a type
declaration looks like. This is necessary now to ensure that plpgsql
will think a 'timestamp' variable has the same semantics as 'timestamp'
does in the main SQL grammar; and it should avoid divergences in future.
Tom Lane [Mon, 8 Oct 2001 21:48:51 +0000 (21:48 +0000)]
Another go-round with FigureColname, to produce less surprising results
for nested typecasts. It now produces a column header of 'timestamptz'
for 'SELECT CURRENT_TIMESTAMP', rather than 'text' as it was doing for
awhile there.
Tom Lane [Mon, 8 Oct 2001 21:46:59 +0000 (21:46 +0000)]
Fix transformExpr() to not scribble on its input datastructure while
transforming CASE expressions. This was definitely confusing
FigureColname, and might lead to bad things elsewhere as well.
Tom Lane [Mon, 8 Oct 2001 19:55:07 +0000 (19:55 +0000)]
Fix ruleutils to depend on format_type, rather than having a private
copy of code that knows about displaying types with typmod info.
Needed so that it does the right thing with timestamp datatypes now.
Tom Lane [Sat, 6 Oct 2001 23:21:45 +0000 (23:21 +0000)]
Rearrange fmgr.c and relcache so that it's possible to keep FmgrInfo
lookup info in the relcache for index access method support functions.
This makes a huge difference for dynamically loaded support functions,
and should save a few cycles even for built-in ones. Also tweak dfmgr.c
so that load_external_function is called only once, not twice, when
doing fmgr_info for a dynamically loaded function. All per performance
gripe from Teodor Sigaev, 5-Oct-01.
Bruce Momjian [Fri, 5 Oct 2001 19:05:54 +0000 (19:05 +0000)]
files attached are Traditional Chinese translations translated
and modified from Simplified Chinese translations for backend,
pgsql, pg_dump and libpq. I've appended their names to zh_TW.po.
Tom Lane [Fri, 5 Oct 2001 17:28:13 +0000 (17:28 +0000)]
Further cleanup of dynahash.c API, in pursuit of portability and
readability. Bizarre '(long *) TRUE' return convention is gone,
in favor of just raising an error internally in dynahash.c when
we detect hashtable corruption. HashTableWalk is gone, in favor
of using hash_seq_search directly, since it had no hope of working
with non-LONGALIGNable datatypes. Simplify some other code that was
made undesirably grotty by promixity to HashTableWalk.