postgresql/src/bin/psql/print.c

1251 lines
25 KiB
C
Raw Normal View History

2000-01-19 00:30:24 +01:00
/*
* psql - the PostgreSQL interactive terminal
*
2005-01-01 06:43:09 +01:00
* Copyright (c) 2000-2005, PostgreSQL Global Development Group
2000-01-19 00:30:24 +01:00
*
* $PostgreSQL: pgsql/src/bin/psql/print.c,v 1.55 2005/02/22 04:40:57 momjian Exp $
2000-01-19 00:30:24 +01:00
*/
#include "postgres_fe.h"
#include "common.h"
#include "print.h"
#include <math.h>
#include <signal.h>
#ifndef WIN32_CLIENT_ONLY
#include <unistd.h>
#endif
#ifndef WIN32
#include <sys/ioctl.h> /* for ioctl() */
#endif
#ifdef HAVE_TERMIOS_H
#include <termios.h>
#endif
2000-02-16 14:15:26 +01:00
#include "pqsignal.h"
#include "libpq-fe.h"
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/ -----
2001-10-15 03:25:10 +02:00
#include "mbprint.h"
/*************************/
1999-11-05 00:14:30 +01:00
/* Unaligned text */
/*************************/
static void
print_unaligned_text(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_fieldsep, const char *opt_recordsep, bool opt_barebones,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
const char *const * ptr;
bool need_recordsep = false;
1999-11-05 00:14:30 +01:00
if (!opt_fieldsep)
opt_fieldsep = "";
if (!opt_recordsep)
opt_recordsep = "";
1999-11-05 00:14:30 +01:00
/* print title */
if (!opt_barebones && title)
2000-01-19 00:30:24 +01:00
fprintf(fout, "%s%s", title, opt_recordsep);
1999-11-05 00:14:30 +01:00
/* print headers and count columns */
for (ptr = headers; *ptr; ptr++)
{
col_count++;
if (!opt_barebones)
{
if (col_count > 1)
fputs(opt_fieldsep, fout);
fputs(*ptr, fout);
}
}
if (!opt_barebones)
need_recordsep = true;
1999-11-05 00:14:30 +01:00
/* print cells */
i = 0;
for (ptr = cells; *ptr; ptr++)
{
if (need_recordsep)
{
2000-01-19 00:30:24 +01:00
fputs(opt_recordsep, fout);
need_recordsep = false;
}
1999-11-05 00:14:30 +01:00
fputs(*ptr, fout);
if ((i + 1) % col_count)
fputs(opt_fieldsep, fout);
else
need_recordsep = true;
1999-11-05 00:14:30 +01:00
i++;
}
1999-11-05 00:14:30 +01:00
/* print footers */
1999-11-05 00:14:30 +01:00
if (!opt_barebones && footers)
for (ptr = footers; *ptr; ptr++)
{
if (need_recordsep)
{
fputs(opt_recordsep, fout);
need_recordsep = false;
}
2000-01-19 00:30:24 +01:00
fputs(*ptr, fout);
need_recordsep = true;
}
/* the last record needs to be concluded with a newline */
if (need_recordsep)
fputc('\n', fout);
}
static void
print_unaligned_vertical(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_fieldsep, const char *opt_recordsep, bool opt_barebones,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
if (!opt_fieldsep)
opt_fieldsep = "";
if (!opt_recordsep)
opt_recordsep = "";
1999-11-05 00:14:30 +01:00
/* print title */
if (!opt_barebones && title)
fputs(title, fout);
1999-11-05 00:14:30 +01:00
/* count columns */
for (ptr = headers; *ptr; ptr++)
col_count++;
/* print records */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
if (i != 0 || (!opt_barebones && title))
{
fputs(opt_recordsep, fout);
if (i % col_count == 0)
fputs(opt_recordsep, fout); /* another one */
}
fputs(headers[i % col_count], fout);
fputs(opt_fieldsep, fout);
fputs(*ptr, fout);
}
1999-11-05 00:14:30 +01:00
/* print footers */
2000-01-19 00:30:24 +01:00
if (!opt_barebones && footers && *footers)
1999-11-05 00:14:30 +01:00
{
fputs(opt_recordsep, fout);
1999-11-05 00:14:30 +01:00
for (ptr = footers; *ptr; ptr++)
{
fputs(opt_recordsep, fout);
fputs(*ptr, fout);
}
1999-11-05 00:14:30 +01:00
}
2000-01-19 00:30:24 +01:00
fputc('\n', fout);
}
/********************/
1999-11-05 00:14:30 +01:00
/* Aligned text */
/********************/
/* draw "line" */
static void
1999-11-05 00:14:30 +01:00
_print_horizontal_line(const unsigned int col_count, const unsigned int *widths, unsigned short border, FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int i,
j;
if (border == 1)
fputc('-', fout);
else if (border == 2)
fputs("+-", fout);
for (i = 0; i < col_count; i++)
{
for (j = 0; j < widths[i]; j++)
fputc('-', fout);
if (i < col_count - 1)
{
if (border == 0)
fputc(' ', fout);
else
fputs("-+-", fout);
}
}
if (border == 2)
fputs("-+", fout);
else if (border == 1)
fputc('-', fout);
fputc('\n', fout);
}
static void
print_aligned_text(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
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/ -----
2001-10-15 03:25:10 +02:00
const char *opt_align, bool opt_barebones,
unsigned short int opt_border, int encoding,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
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/ -----
2001-10-15 03:25:10 +02:00
unsigned int cell_count = 0;
unsigned int *head_w,
*cell_w;
1999-11-05 00:14:30 +01:00
unsigned int i,
tmp;
unsigned int *widths,
total_w;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
/* count columns */
for (ptr = headers; *ptr; ptr++)
col_count++;
if (col_count > 0)
1999-11-05 00:14:30 +01:00
{
widths = calloc(col_count, sizeof(*widths));
if (!widths)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
head_w = calloc(col_count, sizeof(*head_w));
if (!head_w)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
}
else
{
widths = NULL;
head_w = NULL;
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/ -----
2001-10-15 03:25:10 +02:00
}
/* count cells (rows * cols) */
for (ptr = cells; *ptr; ptr++)
cell_count++;
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/ -----
2001-10-15 03:25:10 +02:00
2001-10-29 07:45:32 +01:00
if (cell_count > 0)
{
cell_w = calloc(cell_count, sizeof(*cell_w));
if (!cell_w)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
2001-10-29 07:45:32 +01:00
}
else
cell_w = NULL;
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/ -----
2001-10-15 03:25:10 +02:00
1999-11-05 00:14:30 +01:00
/* calc column widths */
for (i = 0; i < col_count; i++)
{
tmp = pg_wcswidth((unsigned char *) headers[i], strlen(headers[i]), encoding);
if (tmp > widths[i])
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/ -----
2001-10-15 03:25:10 +02:00
widths[i] = tmp;
head_w[i] = tmp;
}
1999-11-05 00:14:30 +01:00
for (i = 0, ptr = cells; *ptr; ptr++, i++)
{
tmp = pg_wcswidth((unsigned char *) *ptr, strlen(*ptr), encoding);
if (tmp > widths[i % col_count])
1999-11-05 00:14:30 +01:00
widths[i % col_count] = tmp;
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/ -----
2001-10-15 03:25:10 +02:00
cell_w[i] = tmp;
}
1999-11-05 00:14:30 +01:00
if (opt_border == 0)
total_w = col_count - 1;
else if (opt_border == 1)
total_w = col_count * 3 - 1;
else
1999-11-05 00:14:30 +01:00
total_w = col_count * 3 + 1;
for (i = 0; i < col_count; i++)
total_w += widths[i];
/* print title */
if (title && !opt_barebones)
{
tmp = pg_wcswidth((unsigned char *) title, strlen(title), encoding);
if (tmp >= total_w)
1999-11-05 00:14:30 +01:00
fprintf(fout, "%s\n", title);
else
fprintf(fout, "%-*s%s\n", (total_w - tmp) / 2, "", title);
}
1999-11-05 00:14:30 +01:00
/* print headers */
if (!opt_barebones)
{
if (opt_border == 2)
_print_horizontal_line(col_count, widths, opt_border, fout);
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fputs("| ", fout);
else if (opt_border == 1)
fputc(' ', fout);
for (i = 0; i < col_count; i++)
{
2003-08-04 02:43:34 +02:00
unsigned int nbspace;
nbspace = widths[i] - head_w[i];
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/ -----
2001-10-15 03:25:10 +02:00
1999-11-05 00:14:30 +01:00
/* centered */
fprintf(fout, "%-*s%s%-*s",
nbspace / 2, "", headers[i], (nbspace + 1) / 2, "");
1999-11-05 00:14:30 +01:00
if (i < col_count - 1)
{
if (opt_border == 0)
fputc(' ', fout);
else
fputs(" | ", fout);
}
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fputs(" |", fout);
else if (opt_border == 1)
fputc(' ', fout);;
fputc('\n', fout);
1999-11-05 00:14:30 +01:00
_print_horizontal_line(col_count, widths, opt_border, fout);
}
1999-11-05 00:14:30 +01:00
/* print cells */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
/* beginning of line */
if (i % col_count == 0)
{
if (opt_border == 2)
fputs("| ", fout);
else if (opt_border == 1)
fputc(' ', fout);
}
/* content */
if (opt_align[i % col_count] == 'r')
{
fprintf(fout, "%*s%s",
widths[i % col_count] - cell_w[i], "", cells[i]);
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/ -----
2001-10-15 03:25:10 +02:00
}
1999-11-05 00:14:30 +01:00
else
{
if ((i + 1) % col_count == 0 && opt_border != 2)
fputs(cells[i], fout);
else
fprintf(fout, "%-s%*s", cells[i],
widths[i % col_count] - cell_w[i], "");
1999-11-05 00:14:30 +01:00
}
/* divider */
if ((i + 1) % col_count)
{
if (opt_border == 0)
fputc(' ', fout);
else
fputs(" | ", fout);
}
/* end of line */
else
{
if (opt_border == 2)
fputs(" |", fout);
fputc('\n', fout);
}
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
_print_horizontal_line(col_count, widths, opt_border, fout);
1999-11-05 00:14:30 +01:00
/* print footers */
if (footers && !opt_barebones)
for (ptr = footers; *ptr; ptr++)
fprintf(fout, "%s\n", *ptr);
#ifndef __MINGW32__
2004-08-29 07:07:03 +02:00
/*
* for some reason MinGW outputs an extra newline, so this supresses
* it
*/
1999-11-05 00:14:30 +01:00
fputc('\n', fout);
#endif
1999-11-05 00:14:30 +01:00
/* clean up */
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/ -----
2001-10-15 03:25:10 +02:00
free(cell_w);
free(head_w);
1999-11-05 00:14:30 +01:00
free(widths);
}
static void
print_aligned_vertical(const char *title, const char *const * headers,
2003-08-04 02:43:34 +02:00
const char *const * cells, const char *const * footers,
bool opt_barebones, unsigned short int opt_border,
int encoding, FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int record = 1;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
unsigned int i,
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/ -----
2001-10-15 03:25:10 +02:00
tmp = 0,
1999-11-05 00:14:30 +01:00
hwidth = 0,
dwidth = 0;
char *divider;
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/ -----
2001-10-15 03:25:10 +02:00
unsigned int cell_count = 0;
unsigned int *cell_w,
*head_w;
1999-11-05 00:14:30 +01:00
if (cells[0] == NULL)
{
puts(_("(No rows)\n"));
return;
}
/* count headers and find longest one */
for (ptr = headers; *ptr; ptr++)
col_count++;
if (col_count > 0)
{
head_w = calloc(col_count, sizeof(*head_w));
if (!head_w)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
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/ -----
2001-10-15 03:25:10 +02:00
}
else
head_w = NULL;
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/ -----
2001-10-15 03:25:10 +02:00
for (i = 0; i < col_count; i++)
{
tmp = pg_wcswidth((unsigned char *) headers[i], strlen(headers[i]), encoding);
if (tmp > hwidth)
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/ -----
2001-10-15 03:25:10 +02:00
hwidth = tmp;
head_w[i] = tmp;
}
/* Count cells, find their lengths */
for (ptr = cells; *ptr; ptr++)
cell_count++;
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/ -----
2001-10-15 03:25:10 +02:00
2001-10-29 07:45:32 +01:00
if (cell_count > 0)
{
cell_w = calloc(cell_count, sizeof(*cell_w));
if (!cell_w)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
2001-10-29 07:45:32 +01:00
}
else
cell_w = NULL;
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/ -----
2001-10-15 03:25:10 +02:00
/* find longest data cell */
for (i = 0, ptr = cells; *ptr; ptr++, i++)
{
tmp = pg_wcswidth((unsigned char *) *ptr, strlen(*ptr), encoding);
if (tmp > dwidth)
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/ -----
2001-10-15 03:25:10 +02:00
dwidth = tmp;
cell_w[i] = tmp;
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/ -----
2001-10-15 03:25:10 +02:00
}
1999-11-05 00:14:30 +01:00
/* print title */
if (!opt_barebones && title)
fprintf(fout, "%s\n", title);
/* make horizontal border */
divider = malloc(hwidth + dwidth + 10);
if (!divider)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
1999-11-05 00:14:30 +01:00
divider[0] = '\0';
if (opt_border == 2)
1999-11-05 00:14:30 +01:00
strcat(divider, "+-");
for (i = 0; i < hwidth; i++)
strcat(divider, opt_border > 0 ? "-" : " ");
if (opt_border > 0)
1999-11-05 00:14:30 +01:00
strcat(divider, "-+-");
else
1999-11-05 00:14:30 +01:00
strcat(divider, " ");
for (i = 0; i < dwidth; i++)
strcat(divider, opt_border > 0 ? "-" : " ");
if (opt_border == 2)
strcat(divider, "-+");
/* print records */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
if (i % col_count == 0)
{
if (!opt_barebones)
{
char *record_str = malloc(32);
1999-11-05 00:14:30 +01:00
size_t record_str_len;
if (!record_str)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
1999-11-05 00:14:30 +01:00
if (opt_border == 0)
snprintf(record_str, 32, "* Record %d", record++);
1999-11-05 00:14:30 +01:00
else
snprintf(record_str, 32, "[ RECORD %d ]", record++);
1999-11-05 00:14:30 +01:00
record_str_len = strlen(record_str);
if (record_str_len + opt_border > strlen(divider))
fprintf(fout, "%.*s%s\n", opt_border, divider, record_str);
else
{
char *div_copy = strdup(divider);
if (!div_copy)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
strncpy(div_copy + opt_border, record_str, record_str_len);
fprintf(fout, "%s\n", div_copy);
free(div_copy);
}
1999-11-05 00:14:30 +01:00
free(record_str);
}
else if (i != 0 || opt_border == 2)
1999-11-05 00:14:30 +01:00
fprintf(fout, "%s\n", divider);
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fputs("| ", fout);
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/ -----
2001-10-15 03:25:10 +02:00
fprintf(fout, "%-s%*s", headers[i % col_count],
hwidth - head_w[i % col_count], "");
1999-11-05 00:14:30 +01:00
if (opt_border > 0)
fputs(" | ", fout);
else
fputs(" ", fout);
1999-11-05 00:14:30 +01:00
if (opt_border < 2)
fprintf(fout, "%s\n", *ptr);
else
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/ -----
2001-10-15 03:25:10 +02:00
fprintf(fout, "%-s%*s |\n", *ptr, dwidth - cell_w[i], "");
1999-11-05 00:14:30 +01:00
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fprintf(fout, "%s\n", divider);
1999-11-05 00:14:30 +01:00
/* print footers */
1999-11-05 00:14:30 +01:00
if (!opt_barebones && footers && *footers)
{
if (opt_border < 2)
fputc('\n', fout);
for (ptr = footers; *ptr; ptr++)
fprintf(fout, "%s\n", *ptr);
}
1999-11-05 00:14:30 +01:00
fputc('\n', fout);
free(divider);
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/ -----
2001-10-15 03:25:10 +02:00
free(cell_w);
free(head_w);
}
/**********************/
/* HTML printing ******/
/**********************/
void
1999-11-05 00:14:30 +01:00
html_escaped_print(const char *in, FILE *fout)
{
1999-11-05 00:14:30 +01:00
const char *p;
for (p = in; *p; p++)
switch (*p)
{
case '&':
fputs("&amp;", fout);
break;
case '<':
fputs("&lt;", fout);
break;
case '>':
fputs("&gt;", fout);
break;
case '\n':
fputs("<br />\n", fout);
break;
case '"':
fputs("&quot;", fout);
break;
case '\'':
fputs("&apos;", fout);
1999-11-05 00:14:30 +01:00
break;
default:
fputc(*p, fout);
}
}
static void
print_html_text(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_align, bool opt_barebones, unsigned short int opt_border,
const char *opt_table_attr,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
fprintf(fout, "<table border=\"%d\"", opt_border);
1999-11-05 00:14:30 +01:00
if (opt_table_attr)
fprintf(fout, " %s", opt_table_attr);
fputs(">\n", fout);
/* print title */
if (!opt_barebones && title)
{
fputs(" <caption>", fout);
html_escaped_print(title, fout);
fputs("</caption>\n", fout);
}
1999-11-05 00:14:30 +01:00
/* print headers and count columns */
if (!opt_barebones)
fputs(" <tr>\n", fout);
for (i = 0, ptr = headers; *ptr; i++, ptr++)
{
col_count++;
if (!opt_barebones)
{
fputs(" <th align=\"center\">", fout);
1999-11-05 00:14:30 +01:00
html_escaped_print(*ptr, fout);
fputs("</th>\n", fout);
}
}
if (!opt_barebones)
fputs(" </tr>\n", fout);
/* print cells */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
if (i % col_count == 0)
fputs(" <tr valign=\"top\">\n", fout);
1999-11-05 00:14:30 +01:00
fprintf(fout, " <td align=\"%s\">", opt_align[(i) % col_count] == 'r' ? "right" : "left");
2003-08-04 02:43:34 +02:00
if ((*ptr)[strspn(*ptr, " \t")] == '\0') /* is string only
* whitespace? */
fputs("&nbsp; ", fout);
1999-11-05 00:14:30 +01:00
else
html_escaped_print(*ptr, fout);
fputs("</td>\n", fout);
1999-11-05 00:14:30 +01:00
if ((i + 1) % col_count == 0)
fputs(" </tr>\n", fout);
}
1999-11-05 00:14:30 +01:00
fputs("</table>\n", fout);
1999-11-05 00:14:30 +01:00
/* print footers */
if (!opt_barebones && footers && *footers)
{
fputs("<p>", fout);
1999-11-05 00:14:30 +01:00
for (ptr = footers; *ptr; ptr++)
{
html_escaped_print(*ptr, fout);
fputs("<br />\n", fout);
1999-11-05 00:14:30 +01:00
}
fputs("</p>", fout);
}
1999-11-05 00:14:30 +01:00
fputc('\n', fout);
}
static void
print_html_vertical(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_align, bool opt_barebones, unsigned short int opt_border,
const char *opt_table_attr,
1999-11-05 00:14:30 +01:00
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
unsigned int record = 1;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
fprintf(fout, "<table border=\"%d\"", opt_border);
1999-11-05 00:14:30 +01:00
if (opt_table_attr)
fprintf(fout, " %s", opt_table_attr);
fputs(">\n", fout);
/* print title */
if (!opt_barebones && title)
{
fputs(" <caption>", fout);
html_escaped_print(title, fout);
fputs("</caption>\n", fout);
}
1999-11-05 00:14:30 +01:00
/* count columns */
for (ptr = headers; *ptr; ptr++)
col_count++;
1999-11-05 00:14:30 +01:00
/* print records */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
if (i % col_count == 0)
{
if (!opt_barebones)
fprintf(fout, "\n <tr><td colspan=\"2\" align=\"center\">Record %d</td></tr>\n", record++);
1999-11-05 00:14:30 +01:00
else
fputs("\n <tr><td colspan=\"2\">&nbsp;</td></tr>\n", fout);
1999-11-05 00:14:30 +01:00
}
fputs(" <tr valign=\"top\">\n"
1999-11-05 00:14:30 +01:00
" <th>", fout);
html_escaped_print(headers[i % col_count], fout);
fputs("</th>\n", fout);
fprintf(fout, " <td align=\"%s\">", opt_align[i % col_count] == 'r' ? "right" : "left");
2003-08-04 02:43:34 +02:00
if ((*ptr)[strspn(*ptr, " \t")] == '\0') /* is string only
* whitespace? */
fputs("&nbsp; ", fout);
1999-11-05 00:14:30 +01:00
else
html_escaped_print(*ptr, fout);
fputs("</td>\n </tr>\n", fout);
}
1999-11-05 00:14:30 +01:00
fputs("</table>\n", fout);
/* print footers */
if (!opt_barebones && footers && *footers)
{
fputs("<p>", fout);
1999-11-05 00:14:30 +01:00
for (ptr = footers; *ptr; ptr++)
{
html_escaped_print(*ptr, fout);
fputs("<br />\n", fout);
1999-11-05 00:14:30 +01:00
}
fputs("</p>", fout);
}
1999-11-05 00:14:30 +01:00
fputc('\n', fout);
}
/*************************/
/* LaTeX */
/*************************/
static void
1999-11-05 00:14:30 +01:00
latex_escaped_print(const char *in, FILE *fout)
{
1999-11-05 00:14:30 +01:00
const char *p;
for (p = in; *p; p++)
switch (*p)
{
case '&':
fputs("\\&", fout);
break;
case '%':
fputs("\\%", fout);
break;
case '$':
fputs("\\$", fout);
break;
case '_':
fputs("\\_", fout);
break;
1999-11-05 00:14:30 +01:00
case '{':
fputs("\\{", fout);
break;
case '}':
fputs("\\}", fout);
break;
case '\\':
fputs("\\backslash", fout);
break;
case '\n':
fputs("\\\\", fout);
break;
default:
fputc(*p, fout);
}
}
static void
print_latex_text(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_align, bool opt_barebones, unsigned short int opt_border,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
/* print title */
if (!opt_barebones && title)
{
2000-01-19 00:30:24 +01:00
fputs("\\begin{center}\n", fout);
1999-11-05 00:14:30 +01:00
latex_escaped_print(title, fout);
2000-01-19 00:30:24 +01:00
fputs("\n\\end{center}\n\n", fout);
}
/* count columns */
for (ptr = headers; *ptr; ptr++)
col_count++;
1999-11-05 00:14:30 +01:00
/* begin environment and set alignments and borders */
fputs("\\begin{tabular}{", fout);
if (opt_border == 2)
2004-08-29 07:07:03 +02:00
fputs("| ", fout);
for (i = 0; i < col_count; i++)
1999-11-05 00:14:30 +01:00
{
2004-08-29 07:07:03 +02:00
fputc(*(opt_align + i), fout);
if (opt_border != 0 && i < col_count - 1)
fputs(" | ", fout);
1999-11-05 00:14:30 +01:00
}
if (opt_border == 2)
2004-08-29 07:07:03 +02:00
fputs(" |", fout);
1999-11-05 00:14:30 +01:00
fputs("}\n", fout);
1999-11-05 00:14:30 +01:00
if (!opt_barebones && opt_border == 2)
fputs("\\hline\n", fout);
1999-11-05 00:14:30 +01:00
/* print headers and count columns */
for (i = 0, ptr = headers; i < col_count; i++, ptr++)
1999-11-05 00:14:30 +01:00
{
if (!opt_barebones)
{
if (i != 0)
fputs(" & ", fout);
2004-08-29 07:07:03 +02:00
fputs("\\textit{", fout);
1999-11-05 00:14:30 +01:00
latex_escaped_print(*ptr, fout);
2004-08-29 07:07:03 +02:00
fputc('}', fout);
1999-11-05 00:14:30 +01:00
}
}
if (!opt_barebones)
{
fputs(" \\\\\n", fout);
fputs("\\hline\n", fout);
}
/* print cells */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
latex_escaped_print(*ptr, fout);
1999-11-05 00:14:30 +01:00
if ((i + 1) % col_count == 0)
fputs(" \\\\\n", fout);
else
fputs(" & ", fout);
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fputs("\\hline\n", fout);
fputs("\\end{tabular}\n\n\\noindent ", fout);
1999-11-05 00:14:30 +01:00
/* print footers */
1999-11-05 00:14:30 +01:00
if (footers && !opt_barebones)
for (ptr = footers; *ptr; ptr++)
{
latex_escaped_print(*ptr, fout);
fputs(" \\\\\n", fout);
}
fputc('\n', fout);
}
static void
print_latex_vertical(const char *title, const char *const * headers,
const char *const * cells, const char *const * footers,
const char *opt_align, bool opt_barebones, unsigned short int opt_border,
FILE *fout)
{
1999-11-05 00:14:30 +01:00
unsigned int col_count = 0;
unsigned int i;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
unsigned int record = 1;
(void) opt_align; /* currently unused parameter */
/* print title */
if (!opt_barebones && title)
{
2000-01-19 00:30:24 +01:00
fputs("\\begin{center}\n", fout);
1999-11-05 00:14:30 +01:00
latex_escaped_print(title, fout);
2000-01-19 00:30:24 +01:00
fputs("\n\\end{center}\n\n", fout);
}
1999-11-05 00:14:30 +01:00
/* begin environment and set alignments and borders */
fputs("\\begin{tabular}{", fout);
if (opt_border == 0)
fputs("cl", fout);
else if (opt_border == 1)
fputs("c|l", fout);
else if (opt_border == 2)
fputs("|c|l|", fout);
fputs("}\n", fout);
1999-11-05 00:14:30 +01:00
/* count columns */
for (ptr = headers; *ptr; ptr++)
col_count++;
1999-11-05 00:14:30 +01:00
/* print records */
for (i = 0, ptr = cells; *ptr; i++, ptr++)
{
/* new record */
if (i % col_count == 0)
{
if (!opt_barebones)
{
if (opt_border == 2)
{
1999-11-05 00:14:30 +01:00
fputs("\\hline\n", fout);
fprintf(fout, "\\multicolumn{2}{|c|}{\\textit{Record %d}} \\\\\n", record++);
}
else
fprintf(fout, "\\multicolumn{2}{c}{\\textit{Record %d}} \\\\\n", record++);
1999-11-05 00:14:30 +01:00
}
if (opt_border >= 1)
fputs("\\hline\n", fout);
}
1999-11-05 00:14:30 +01:00
latex_escaped_print(headers[i % col_count], fout);
fputs(" & ", fout);
latex_escaped_print(*ptr, fout);
fputs(" \\\\\n", fout);
}
1999-11-05 00:14:30 +01:00
if (opt_border == 2)
fputs("\\hline\n", fout);
fputs("\\end{tabular}\n\n\\noindent ", fout);
1999-11-05 00:14:30 +01:00
/* print footers */
if (footers && !opt_barebones)
for (ptr = footers; *ptr; ptr++)
{
latex_escaped_print(*ptr, fout);
fputs(" \\\\\n", fout);
}
fputc('\n', fout);
}
/********************************/
/* Public functions */
/********************************/
/*
* PageOutput
*
* Tests if pager is needed and returns appropriate FILE pointer.
*/
FILE *
PageOutput(int lines, unsigned short int pager)
{
/* check whether we need / can / are supposed to use pager */
if (pager
#ifndef WIN32
&&
isatty(fileno(stdin)) &&
isatty(fileno(stdout))
#endif
)
{
const char *pagerprog;
#ifdef TIOCGWINSZ
int result;
struct winsize screen_size;
result = ioctl(fileno(stdout), TIOCGWINSZ, &screen_size);
/* >= accounts for a one-line prompt */
if (result == -1 || lines >= screen_size.ws_row || pager > 1)
{
#endif
pagerprog = getenv("PAGER");
if (!pagerprog)
pagerprog = DEFAULT_PAGER;
#ifndef WIN32
pqsignal(SIGPIPE, SIG_IGN);
#endif
return popen(pagerprog, "w");
#ifdef TIOCGWINSZ
}
#endif
}
return stdout;
}
void
printTable(const char *title,
const char *const * headers,
const char *const * cells,
const char *const * footers,
const char *align,
const printTableOpt *opt, FILE *fout)
{
const char *default_footer[] = {NULL};
1999-11-05 00:14:30 +01:00
unsigned short int border = opt->border;
2003-08-04 02:43:34 +02:00
FILE *output;
1999-11-05 00:14:30 +01:00
if (opt->format == PRINT_NOTHING)
return;
1999-11-05 00:14:30 +01:00
if (!footers)
footers = default_footer;
1999-11-05 00:14:30 +01:00
if (opt->format != PRINT_HTML && border > 2)
border = 2;
if (fout == stdout)
1999-11-05 00:14:30 +01:00
{
2003-08-04 02:43:34 +02:00
int col_count = 0,
row_count = 0,
lines;
const char *const * ptr;
1999-11-05 00:14:30 +01:00
/* rough estimate of columns and rows */
if (headers)
for (ptr = headers; *ptr; ptr++)
col_count++;
if (cells)
for (ptr = cells; *ptr; ptr++)
row_count++;
2002-04-24 17:56:38 +02:00
if (col_count > 0)
row_count /= col_count;
1999-11-05 00:14:30 +01:00
if (opt->expanded)
lines = (col_count + 1) * row_count;
else
lines = row_count + 1;
if (footers && !opt->tuples_only)
for (ptr = footers; *ptr; ptr++)
lines++;
output = PageOutput(lines, opt->pager);
1999-11-05 00:14:30 +01:00
}
else
1999-11-05 00:14:30 +01:00
output = fout;
/* print the stuff */
switch (opt->format)
{
case PRINT_UNALIGNED:
if (opt->expanded)
2000-01-19 00:30:24 +01:00
print_unaligned_vertical(title, headers, cells, footers, opt->fieldSep, opt->recordSep, opt->tuples_only, output);
1999-11-05 00:14:30 +01:00
else
2000-01-19 00:30:24 +01:00
print_unaligned_text(title, headers, cells, footers, opt->fieldSep, opt->recordSep, opt->tuples_only, output);
1999-11-05 00:14:30 +01:00
break;
case PRINT_ALIGNED:
if (opt->expanded)
print_aligned_vertical(title, headers, cells, footers, opt->tuples_only, border, opt->encoding, output);
1999-11-05 00:14:30 +01:00
else
print_aligned_text(title, headers, cells, footers, align, opt->tuples_only, border, opt->encoding, output);
1999-11-05 00:14:30 +01:00
break;
case PRINT_HTML:
if (opt->expanded)
print_html_vertical(title, headers, cells, footers, align, opt->tuples_only, border, opt->tableAttr, output);
else
print_html_text(title, headers, cells, footers, align, opt->tuples_only, border, opt->tableAttr, output);
break;
case PRINT_LATEX:
if (opt->expanded)
print_latex_vertical(title, headers, cells, footers, align, opt->tuples_only, border, output);
else
print_latex_text(title, headers, cells, footers, align, opt->tuples_only, border, output);
break;
default:
fprintf(stderr, "+ Oops, you shouldn't see this!\n");
}
/* Only close if we used the pager */
if (fout == stdout && output != stdout)
1999-11-05 00:14:30 +01:00
{
pclose(output);
#ifndef WIN32
1999-11-05 00:14:30 +01:00
pqsignal(SIGPIPE, SIG_DFL);
#endif
1999-11-05 00:14:30 +01:00
}
}
void
printQuery(const PGresult *result, const printQueryOpt *opt, FILE *fout)
{
1999-11-05 00:14:30 +01:00
int nfields;
2004-05-24 00:20:10 +02:00
int ncells;
const char **headers;
const char **cells;
char **footers;
char *align;
1999-11-05 00:14:30 +01:00
int i;
/* extract headers */
nfields = PQnfields(result);
headers = calloc(nfields + 1, sizeof(*headers));
if (!headers)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
for (i = 0; i < nfields; i++)
headers[i] = mbvalidate(PQfname(result, i), opt->topt.encoding);
1999-11-05 00:14:30 +01:00
/* set cells */
2004-05-24 00:20:10 +02:00
ncells = PQntuples(result) * nfields;
cells = calloc(ncells + 1, sizeof(*cells));
if (!cells)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
2004-05-24 00:20:10 +02:00
for (i = 0; i < ncells; i++)
1999-11-05 00:14:30 +01:00
{
if (PQgetisnull(result, i / nfields, i % nfields))
cells[i] = opt->nullPrint ? opt->nullPrint : "";
else
cells[i] = mbvalidate(PQgetvalue(result, i / nfields, i % nfields), opt->topt.encoding);
1999-11-05 00:14:30 +01:00
}
1999-11-05 00:14:30 +01:00
/* set footers */
1999-11-05 00:14:30 +01:00
if (opt->footers)
footers = opt->footers;
else if (!opt->topt.expanded && opt->default_footer)
1999-11-05 00:14:30 +01:00
{
footers = calloc(2, sizeof(*footers));
if (!footers)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
footers[0] = malloc(100);
2004-05-24 00:20:10 +02:00
if (!footers[0])
{
fprintf(stderr, _("out of memory\n"));
2004-05-24 00:20:10 +02:00
exit(EXIT_FAILURE);
}
1999-11-05 00:14:30 +01:00
if (PQntuples(result) == 1)
snprintf(footers[0], 100, _("(1 row)"));
1999-11-05 00:14:30 +01:00
else
snprintf(footers[0], 100, _("(%d rows)"), PQntuples(result));
1999-11-05 00:14:30 +01:00
}
else
1999-11-05 00:14:30 +01:00
footers = NULL;
1999-11-05 00:14:30 +01:00
/* set alignment */
align = calloc(nfields + 1, sizeof(*align));
if (!align)
{
fprintf(stderr, _("out of memory\n"));
exit(EXIT_FAILURE);
}
1999-11-05 00:14:30 +01:00
for (i = 0; i < nfields; i++)
{
Oid ftype = PQftype(result, i);
if (ftype == 20 || /* int8 */
ftype == 21 || /* int2 */
ftype == 23 || /* int4 */
(ftype >= 26 && ftype <= 30) || /* ?id */
ftype == 700 || /* float4 */
ftype == 701 || /* float8 */
ftype == 790 || /* money */
ftype == 1700 /* numeric */
)
align[i] = 'r';
else
align[i] = 'l';
}
1999-11-05 00:14:30 +01:00
/* call table printer */
printTable(opt->title, headers, cells,
2004-05-24 00:20:10 +02:00
(const char *const *) footers,
align, &opt->topt, fout);
2004-05-24 00:20:10 +02:00
free(headers);
free(cells);
1999-11-05 00:14:30 +01:00
if (footers)
{
free(footers[0]);
free(footers);
}
2001-03-01 19:52:50 +01:00
free(align);
}
/* the end */