view when using the aggregate function count() and function nextval
that returns an int8 value, but in python is represented like string:

>> db.query("select nextval('my_seq')").getresult()
[('2',)]

>> db.query("select count(*) from films").dictresult()
[{'count': '120'}]



Ricardo Caesar Lenzi

2 is our "official" name, and 3 is alias). If there's no objection, I
will change them.

ASCII		SQL_ASCII
UTF-8		UNICODE		UTF_8
MULE-INTERNAL	MULE_INTERNAL
ISO-8859-1	LATIN1		ISO_8859_1
ISO-8859-2	LATIN2		ISO_8859_2
ISO-8859-3	LATIN3		ISO_8859_3
ISO-8859-4	LATIN4		ISO_8859_4
ISO-8859-5	ISO_8859_5
ISO-8859-6	ISO_8859_6
ISO-8859-7	ISO_8859_7
ISO-8859-8	ISO_8859_8
ISO-8859-9	LATIN5		ISO_8859_9
ISO-8859-10	LATIN6		ISO_8859_10
ISO-8859-13	LATIN7		ISO_8859_13
ISO-8859-14	LATIN8		ISO_8859_14
ISO-8859-15	LATIN9		ISO_8859_15
ISO-8859-16	LATIN10		ISO_8859_16

of the new pg_stats view.

pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous
small improvements.

 > ! $$ = 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.

Lee Kindness

Here is another one :)
Another chunk of translated messages.
Please apply to the same file.

Serguei Mokhov

> - 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/ -----

as the example claimed, because of changes elsewhere in the system.

last commit very carefully...)

        - Synced preproc.y with gram.y.

NUMERIC values that are out of the range of 'double'.  Per trouble
report from Mike Quinn.

streets than it used to...

things with closed paths --- ie, include the closing line segment in
their calculations.  Per bug report from Curtis Barrett 9-Oct-01.

for the PG_DUMP component.

Please apply to </src/bin/pg_dump/ru.po>

Serguei A. Mokhov

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.

Patch includes changes to documentation.