Re: [HACKERS] Escaping strings for inclusion into SQL queries
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch removed at the request of the author. Author will resubmit.
I've attached the fixed version of the patch below. After the
discussion on pgsql-hackers (especially the frightening memory dump in
<[EMAIL PROTECTED]>), we decided that it is best not to
use identifiers from an untrusted source at all. Therefore, all
claims of the suitability of PQescapeString() for identifiers have
been removed.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Index: doc/src/sgml/libpq.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.68
diff -u -r1.68 libpq.sgml
--- doc/src/sgml/libpq.sgml 2001/09/04 00:18:18 1.68
+++ doc/src/sgml/libpq.sgml 2001/09/04 18:32:05
@@ -827,6 +827,42 @@
+
+ Escaping strings for inclusion in SQL queries
+
+PQescapeString
+ Escapes a string for use within an SQL query.
+
+size_t PQescapeString (char *to, const char *from, size_t length);
+
+If you want to include strings which have been received
+from a source which is not trustworthy (for example, because they were
+transmitted across a network), you cannot directly include them in SQL
+queries for security reasons. Instead, you have to quote special
+characters which are otherwise interpreted by the SQL parser.
+
+
+PQescapeString performs this operation. The
+from points to the first character of the string which
+is to be escaped, and the length parameter counts the
+number of characters in this string (a terminating NUL character is
+neither necessary nor counted). to shall point to a
+buffer which is able to hold at least one more character than twice
+the value of length, otherwise the behavior is
+undefined. A call to PQescapeString writes an escaped
+version of the from string to the to
+buffer, replacing special characters so that they cannot cause any
+harm, and adding a terminating NUL character. The single quotes which
+must surround PostgreSQL string literals are not part of the result
+string.
+
+
+PQescapeString returns the number of characters written
+to to, not including the terminating NUL character.
+Behavior is undefined when the to and from
+strings overlap.
+
+
Retrieving SELECT Result Information
Index: src/interfaces/libpq/fe-exec.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.108
diff -u -r1.108 fe-exec.c
--- src/interfaces/libpq/fe-exec.c 2001/08/21 20:39:53 1.108
+++ src/interfaces/libpq/fe-exec.c 2001/09/04 18:32:09
@@ -56,6 +56,62 @@
static int getNotify(PGconn *conn);
static int getNotice(PGconn *conn);
+/* ---
+ * Escaping arbitrary strings to get valid SQL strings/identifiers.
+ *
+ * Replaces "\\" with "", "\0" with "\\0", and "'" with "''".
+ * length is the length of the buffer pointed to by
+ * from. The buffer at to must be at least 2*length + 1 characters
+ * long. A terminating NUL character is written.
+ * ---
+ */
+
+size_t
+PQescapeString (char *to, const char *from, size_t length)
+{
+ const char *source = from;
+ char *target = to;
+ unsigned int remaining = length;
+
+ while (remaining > 0) {
+ switch (*source) {
+ case '\0':
+ *target = '\\';
+ target++;
+ *target = '0';
+ /* target and remaining are updated below. */
+ break;
+
+ case '\\':
+ *target = '\\';
+ target++;
+ *target = '\\';
+ /* target and remaining are updated below. */
+ break;
+
+ case '\'':
+ *target = '\'';
+ target++;
+ *target = '\'';
+ /* target and remaining are updated below. */
+ break;
+
+ default:
+ *target = *source;
+ /* target and remaining are updated below. */
+ }
+ source++;
+ target++;
+ remaining--;
+ }
+
+ /* Write the terminating NUL character. */
+ *target = '\0';
+
+ return target - to;
+}
+
+
/*
* Space management for PGresult.
Index: src/interfaces/libpq/libpq-fe.h
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.72
diff -u -r1.72 libpq-fe.h
--- src/interfaces/libpq/libpq-fe.h
[HACKERS] Referential Integrity Stress Problem
We're running Postgres 7.0.3.2. We're running into a referential
integrity violation that seems to crop up randomly, and only when stress
testing the system for a day or so.
We've created some stress test code to fill the tables with about
500 nodes, then delete them from the top and let the cascade-delete delete
all the children. (the test code is a script for our own scripting
language). Each insert and delete has a trigger that simply rearranges each
node in the table, like a linked list. That trigger code is only a few lines
and doesn't look to be the problem, since the problem only crops up randomly
after several hours of stressing.
The repeated adding and deleting works fine for quite a few hours
with the stress test program, but then randomly it'll error out and give a
referential integrity violation in one of the tables. In the stress code
we'll do a delete from system where system_index = XX and expect it to
cascade delete, but a table, like the bts table, will give something like
"ERROR: bts_fk_constraint referential integrity violation - key referenced
from bts not found in system"
Are there any known bugs in 7.0.3.2 that might cause something like
this to crop up randomly?
Any ideas or things to check would be greatly appreciated.
Here are the 6 tables. It's a parent-child-grandchild relationship. The
table below each table, simply references back to the previous one as the
foreign key, and builds the foreign key from the foreign key of its parent.
create sequence omc_index_seq;
create TABLE omc (
omc_index int4 PRIMARY KEY DEFAULT NEXTVAL('omc_index_seq'),
serial_number varchar(32),
operator_string varchar(255) DEFAULT 'Value not specified.',
debug_level int4 DEFAULT 1,
software_version varchar(32),
hardware_version varchar(32),
software_failure_reason int2
);
create TABLE system (
system_index int4,
display_name varchar(32),
operator_string varchar(255),
id varchar(32),
next_system_index int4,
parent_omc_index int4 NOT NULL,
CONSTRAINT system_fk_constraint FOREIGN KEY (parent_omc_index)
REFERENCES omc (omc_index) ON DELETE CASCADE,
CONSTRAINT system_pkey_constraint PRIMARY KEY (parent_omc_index,
system_index),
CONSTRAINT system_display_name_unique UNIQUE (display_name)
);
create TABLE bts (
bts_index int4,
display_name varchar(32),
operator_string varchar(255),
id varchar(32),
location varchar(255),
next_bts_index int4,
parent_omc_index int4 NOT NULL,
parent_system_index int4 NOT NULL,
CONSTRAINT bts_fk_constraint FOREIGN KEY (parent_omc_index,
parent_system_index)
REFERENCES system (parent_omc_index, system_index) ON DELETE
CASCADE,
CONSTRAINT bts_pkey_constraint PRIMARY KEY (parent_omc_index,
parent_system_index,
bts_index),
CONSTRAINT bts_display_name_unique UNIQUE (display_name,
parent_system_index)
);
create TABLE cell_area (
cell_area_index int4,
display_name varchar(32),
operator_string varchar(255),
cluster_orientation varchar(255),
id varchar(32),
chan_1_link_channel_num int4,
chan_2_link_channel_num int4,
chan_1_coverage_channel_num int4,
chan_2_coverage_channel_num int4,
next_cell_area_index int4,
parent_omc_index int4 NOT NULL,
parent_system_index int4 NOT NULL,
parent_bts_index int4 NOT NULL,
CONSTRAINT cell_area_fk_constraint FOREIGN KEY (parent_omc_index,
parent_system_index,
parent_bts_index)
REFERENCES bts (parent_omc_index, parent_system_index,
bts_index) ON DELETE CASCADE,
CONSTRAINT cell_area_pkey_constraint PRIMARY KEY (parent_omc_index,
parent_system_index,
parent_bts_index,
cell_area_index),
CONSTRAINT cell_area_display_name_unique UNIQUE (display_name,
parent_system_index,
parent_bts_index)
);
create TABLE unit (
unit_index int4,
display_name varchar(32),
operator_string varchar(255),
ip_address varchar(15) UNIQUE NOT NULL,
phone_number varchar(32),
type char(1),
next_unit_index int4,
parent_omc_index int4 NOT NULL,
parent_system_index int4 NOT NULL,
parent_bts_index int4 NOT NULL,
parent_cell_area_index int4 NOT NULL,
CONSTRAINT unit_fk_constraint FOREIGN KEY (parent_omc_index,
Re: [HACKERS] Bad behaviour when inserting unspecified variable length datatypes
>> Uh, what did your CREATE TYPE command look like, exactly? This sounds >> like you specified a default value for the datatype. > [ no, he didn't ] Now that I look at it, CREATE TYPE is totally whacked out about default values for user-defined datatypes. The reason the system-defined types all behave properly is that they are defined (in pg_type.h) with NULL entries in the typdefault field of pg_type. But CREATE TYPE doesn't fill in a NULL when it sees you haven't specified a default! Look at TypeCreate in pg_type.c: /* * initialize the default value for this type. */ values[i] = DirectFunctionCall1(textin,/* 17 */ CStringGetDatum(defaultTypeValue ? defaultTypeValue : "-")); Yech, where'd that come from? It turns out this doesn't hurt fixed-length types unless their length is 1, because there is a test in get_typdefault to verify that the stored value is the expected length. But for var-length types the "-" comes through. A short-term workaround for Dave is to explicitly set pg_type.typdefault to NULL after creating his type, but clearly we gotta clean this up. ISTM that TypeCreate should set typdefault to NULL if it's passed a null default-value item. Another problem here is that there's no mechanism that causes the value stored in typdefault to be correctly converted to the destination type. DefineType and TypeCreate act as though the value is just a text string, but then get_typdefault seems to think that it should find a text object containing the *internal* representation of the desired value. Yech. For example, to make an integer type with a default of 42, I'd have to write default = '\0\0\0\52' (which might or might not even work because of the nulls, and certainly would not do what I wanted on a machine of the other endianness). I propose that we define typdefault as containing the *external* representation of the desired value, and have get_typdefault apply the type's input conversion function to produce a Datum. Any objections? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
Rene,
I would like to add one additional comment. In current sources the jdbc
driver detects (through a hack) that the server doesn't have multibyte
enabled and then ignores the SQL_ASCII return value and defaults to the
JVM's character set instead of using SQL_ASCII.
The problem boils down to the fact that without multibyte enabled, the
server has know way of specifiying which 8bit character set is being
used for a particular database. Thus a client like JDBC doesn't know
what character set to use when converting to UNICODE. Thus the best we
can do in JDBC is use our best guess (JVM character set is probably the
best default), and allow the user to explicitly specify something else
if necessary.
thanks,
--Barry
Rene Pijlman wrote:
> [forwarding to pgsql-hackers and Bruce as Todo list maintainer,
> see comment below]
>
> [insert with JDBC converts Latin-1 umlaut to ?]
> On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote:
>
>>You have to set the encoding when you make the connection.
>>
>>Properties props = new Properties();
>>props.put("user",user);
>>props.put("password",password);
>>props.put("charSet",encoding);
>>Connection con = DriverManager.getConnection(url,props);
>>where encoding is the proper encoding for your database
>>
>
> For completeness, I quote the answer Barry Lind gave yesterday.
>
> "[the driver] asks the server what character set is being used
> for the database. Unfortunatly the server only knows about
> character sets if multibyte support is compiled in. If the
> server is compiled without multibyte, then it always reports to
> the client that the character set is SQL_ASCII (where SQL_ASCII
> is 7bit ascii). Thus if you don't have multibyte enabled on the
> server you can't support 8bit characters through the jdbc
> driver, unless you specifically tell the connection what
> character set to use (i.e. override the default obtained from
> the server)."
>
> This really is confusing and I think PostgreSQL should be able
> to support single byte encoding conversions without enabling
> multi-byte.
>
> To the very least there should be a --enable-encoding-conversion
> or something similar, even if it just enables the current
> multibyte support.
>
> Bruce, can this be put on the TODO list one way or the other?
> This problem has appeared 4 times in two months or so on the
> JDBC list.
>
> Regards,
> René Pijlman <[EMAIL PROTECTED]>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
>
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Let me ask a bigger question. We have the length of the text string in > > the varlena header. Are we concerned about backend code not handling > > NULL in text fields, or frontend code returning strings with embedded > > nulls? > > The former. > > > I see problems in the text() functions for nulls, but is such a > > limitation required for text types? > > Unless you want to re-implement strcoll() and friends from scratch. Yes, I saw strcoll(). -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Escaping strings for inclusion into SQL queries
Patch removed at the request of the author. Author will resubmit. > It has come to our attention that many applications which use libpq > are vulnerable to code insertion attacks in strings and identifiers > passed to these applications. We have collected some evidence which > suggests that this is related to the fact that libpq does not provide > a function to escape strings and identifiers properly. (Both the > Oracle and MySQL client libraries include such a function, and the > vast majority of applications we examined are not vulnerable to code > insertion attacks because they use this function.) > > We therefore suggest that a string escaping function is included in a > future version of PostgreSQL and libpq. A sample implementation is > provided below, along with documentation. > > -- > Florian Weimer [EMAIL PROTECTED] > University of Stuttgart http://cert.uni-stuttgart.de/ > RUS-CERT +49-711-685-5973/fax +49-711-685-5898 [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
Bruce Momjian <[EMAIL PROTECTED]> writes: > Let me ask a bigger question. We have the length of the text string in > the varlena header. Are we concerned about backend code not handling > NULL in text fields, or frontend code returning strings with embedded > nulls? The former. > I see problems in the text() functions for nulls, but is such a > limitation required for text types? Unless you want to re-implement strcoll() and friends from scratch. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
* Tom Lane <[EMAIL PROTECTED]> [010904 12:01]: > They're pretty ugly, but more importantly they're only suitable if we > have exactly one conversion function each way. If we have two, what > will we call the second one? > > I think it's okay to let the argument type be implicit in the function > argument list. Something like text_escaped(bytea) and text_direct(bytea) > (with inverses bytea_escaped(text) and bytea_direct(text)) might do. > I'm not totally happy with "direct" to suggest minimum escaping, though. > Better ideas anyone? Cooked vs raw? LER > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bad behaviour when inserting unspecified variable length
> Uh, what did your CREATE TYPE command look like, exactly? This sounds
> like you specified a default value for the datatype.
Okay, here's two examples;
CREATE TYPE WKB (
internallength = VARIABLE,
input = WKB_in,
output = WKB_out,
storage= extended
);
CREATE TYPE GEOMETRY (
alignment = double,
internallength = VARIABLE,
input = geometry_in,
output = geometry_out,
storage = main
);
I've tried the WKB type with a "DEFAULT = NULL" clause and all the
different storage types. The same problem occurs everytime.
Here's the create function statements for the _in and _out functions;
create function WKB_in(opaque)
RETURNS WKB
AS '@MODULE_FILENAME@','WKB_in'
LANGUAGE 'c' with (isstrict);
create function WKB_out(opaque)
RETURNS opaque
AS '@MODULE_FILENAME@','WKB_out'
LANGUAGE 'c' with (isstrict);
create function geometry_in(opaque)
RETURNS GEOMETRY
AS '@MODULE_FILENAME@'
LANGUAGE 'c' with (isstrict);
create function geometry_out(opaque)
RETURNS opaque
AS '@MODULE_FILENAME@'
LANGUAGE 'c' with (isstrict);
> Maybe you need to show us your datatype's I/O functions, too.
I dont thing they're important. WKB_in and geometry_in are *never*
called, and WKB_out and geometry_out are called with bad values. Only
one line of my code is executed in the _out functions.
WellKnownBinary *WKB = (WellKnownBinary *)
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
or
GEOMETRY *geom1 = (GEOMETRY *)
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
(See below for a simpler example)
> Since
> this works perfectly fine for the standard variable-length datatypes,
Yes, on system (7.1.2 under solaris) the following works;
create table ttt (i integer, mytext text);
insert into ttt values (1);
select * from ttt;
i | mytext
---+
1 |
(1 row)
Here's the simplest example I can come up with to show the problem;
create function WKB_in2(opaque)
RETURNS WKB
AS
'/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.5','WKB_in2'
LANGUAGE 'c' with (isstrict);
create function WKB_out2(opaque)
RETURNS opaque
AS
'/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.5','WKB_out2'
LANGUAGE 'c' with (isstrict);
CREATE TYPE WKB (
internallength = VARIABLE,
input = WKB_in2,
output = WKB_out2,
storage= extended
);
dave=# create table m (i integer, mywkb wkb);
dave=# insert into m values (1);
dave=# select * from m;
i | mywkb
---+---
1 | me
(1 row)
You'll also get this output from the printf in WKB_out (ASCII 45 is the
"-" char);
WKB_out2: WKB has length 5 and 1st value 45
typedef struct Well_known_bin {
int32 size;// total size of this structure
unsigned char data[1]; //THIS HOLDS VARIABLE LENGTH DATA
} WellKnownBinary;
PG_FUNCTION_INFO_V1(WKB_in2);
Datum WKB_in2(PG_FUNCTION_ARGS)
{
char*str = PG_GETARG_CSTRING(0);
printf("I never get here!\n");
PG_RETURN_NULL();
}
PG_FUNCTION_INFO_V1(WKB_out2);
Datum WKB_out2(PG_FUNCTION_ARGS)
{
WellKnownBinary *WKB = (WellKnownBinary *)
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
char*result;
printf("WKB_out2: WKB has length %i and 1st value %i\n", WKB->size,
(int) ((char *)WKB)[4] );
// return something
result = palloc(3);
result[0] = 'm';
result[1] = 'e';
result[2] = 0;
PG_RETURN_CSTRING(result);
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
> You're right, as usual (I was tired when I wrote this last night ;). But I > think we have to escape/unescape both null and '\', don't we? Yes, I think backslashes need special escapes too. Let me ask a bigger question. We have the length of the text string in the varlena header. Are we concerned about backend code not handling NULL in text fields, or frontend code returning strings with embedded nulls? I see problems in the text() functions for nulls, but is such a limitation required for text types? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
[forwarding to pgsql-hackers and Bruce as Todo list maintainer,
see comment below]
[insert with JDBC converts Latin-1 umlaut to ?]
On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote:
>You have to set the encoding when you make the connection.
>
>Properties props = new Properties();
>props.put("user",user);
>props.put("password",password);
>props.put("charSet",encoding);
>Connection con = DriverManager.getConnection(url,props);
>where encoding is the proper encoding for your database
For completeness, I quote the answer Barry Lind gave yesterday.
"[the driver] asks the server what character set is being used
for the database. Unfortunatly the server only knows about
character sets if multibyte support is compiled in. If the
server is compiled without multibyte, then it always reports to
the client that the character set is SQL_ASCII (where SQL_ASCII
is 7bit ascii). Thus if you don't have multibyte enabled on the
server you can't support 8bit characters through the jdbc
driver, unless you specifically tell the connection what
character set to use (i.e. override the default obtained from
the server)."
This really is confusing and I think PostgreSQL should be able
to support single byte encoding conversions without enabling
multi-byte.
To the very least there should be a --enable-encoding-conversion
or something similar, even if it just enables the current
multibyte support.
Bruce, can this be put on the TODO list one way or the other?
This problem has appeared 4 times in two months or so on the
JDBC list.
Regards,
René Pijlman <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
"Joe Conway" <[EMAIL PROTECTED]> writes: > You're right, as usual (I was tired when I wrote this last night ;). But I > think we have to escape/unescape both null and '\', don't we? Yeah, you're right. My turn to have not thought hard enough. > I agree that it would be better to *not* allow implicit coercions. Given > that, any preferences on function names? Are text_to_bytea() and > bytea_to_text() too ugly? They're pretty ugly, but more importantly they're only suitable if we have exactly one conversion function each way. If we have two, what will we call the second one? I think it's okay to let the argument type be implicit in the function argument list. Something like text_escaped(bytea) and text_direct(bytea) (with inverses bytea_escaped(text) and bytea_direct(text)) might do. I'm not totally happy with "direct" to suggest minimum escaping, though. Better ideas anyone? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] to_char and Roman Numeral (RN) bug
> On Fri, Aug 31, 2001 at 07:28:50PM -0700, Command Prompt, Inc. wrote: > > > In documenting the to_char() function for transformation of numbers to > > text, I noticed that the "RN" template character sequence was displaying > > some unusual behavior; specifically, unless in fill mode (with the "FM" > > sequence), it would either return the result of the last query executed > > derived from a to_char() result, or what appears to be a garbage pointer > > if there was no such last query. > > You are right it's bug. For the 'RM' in non-fillmode is to_char() quiet. > I will fix it for 7.2. Karel, I assume you will send in a patch yourself, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
> Ugh ... if the conversion functions are not inverses then I think they > lose much of their value. I could see doing either of these: > > 1. Conversion functions based on byteaout/byteain. > > 2. Bytea to text escapes *only* null bytes, text to bytea treats only > "\0" as an escape sequence. > > Or maybe both, with two pairs of conversion functions. > > In any case, we have to decide whether these coercion functions should > be named after the types --- ie, should they be made invokable as > implicit coercions? I'm dubious that that's a good idea; if we do it > then all sorts of textual operations will suddenly be allowed for bytea > without any explicit conversion, which is likely to do more harm than > good. The reason for having a separate bytea type is exactly so that > you *can't* apply text ops to it without thinking. > > regards, tom lane You're right, as usual (I was tired when I wrote this last night ;). But I think we have to escape/unescape both null and '\', don't we? I agree that it would be better to *not* allow implicit coercions. Given that, any preferences on function names? Are text_to_bytea() and bytea_to_text() too ugly? -- Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] to_char and Roman Numeral (RN) bug
On Tue, Sep 04, 2001 at 11:37:48AM -0400, Bruce Momjian wrote: > > On Fri, Aug 31, 2001 at 07:28:50PM -0700, Command Prompt, Inc. wrote: > > > > > In documenting the to_char() function for transformation of numbers to > > > text, I noticed that the "RN" template character sequence was displaying > > > some unusual behavior; specifically, unless in fill mode (with the "FM" > > > sequence), it would either return the result of the last query executed > > > derived from a to_char() result, or what appears to be a garbage pointer > > > if there was no such last query. > > > > You are right it's bug. For the 'RM' in non-fillmode is to_char() quiet. > > I will fix it for 7.2. > > Karel, I assume you will send in a patch yourself, right? Right. It needs check. Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgres is eating my CPU
[EMAIL PROTECTED] (James Thornton) writes: > As you can see from the ps output, there are several INSERT statements > -- these return after restarting Postgres and even rebooting the > system. Postgres backends don't just appear out of nowhere. Somewhere you have a client app that is connecting to the database and issuing those INSERT commands. Without knowing what that app is or exactly what commands it's issuing, it's impossible to say what's going on. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] getting the oid for a new tuple in a BEFORE
> > we need to control database changes within BEFORE triggers. > > There is no problem with triggers called by update, but there is > > a problem with triggers called by insert. > > > > We strongly need to know the oid of a newly inserted tuple. > > In this case, we use tg_newtuple of the TriggerData structure > > passed to thetrigger function, and its t_data -> t_oid will > > have the value '0'. > > > > Using BEFORE and AFTER triggers would make our lives much harder. > > > > Is there any way (even hack) to get the oid the newly > > inserted tuple will receive? > > Just set t_data->t_oid = newoid() - this is what backend does > in heapam.c:heap_insert(). Does that work? Doesn't that get overwritten when the actual INSERT happens? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
> > On a related note, are there any other bytea functions we should have in the > > backend before freezing for 7.2? > > The SQL standards has a lot of functions for BLOB... > OK - thanks. I'll take a look. > > I was thinking it would be nice to have a > > way to cast bytea into text and vice-versa, so that the normal text > > functions could be used for things like LIKE and concatenation. > > Better write a native LIKE function for bytea, now that some parts are > threatening to make the text-LIKE function use the locale collating > sequence. (Multibyte aware text could also have interesting effects.) > Sounds like good advice. I'll try to get both the cast functions and a native bytea LIKE function done. -- Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Table vs. row level locks confusion
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The following section > http://www.ca.postgresql.org/devel-corner/docs/postgres/locking-tables.html > titled "Locking and Tables", has two subsections, "Table-level locks" and > "Row-level locks". Under table-level locks we find lock names such as > RowShareLock and RowExclusiveLock -- are those table-level locks? Yes, despite the names. (The various lock-type names are pretty horrible IMHO, but they are claimed to be Oracle-compatible.) Anything you do with a LOCK command is a table-level lock. > Under row-level locks we find no specific lock names mentioned. The only row-level locking mechanism available to users is to UPDATE, DELETE, or SELECT FOR UPDATE a particular row. All rows affected by such a command are locked against other such commands (but not against plain SELECT). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] [BUGS] Build problem with CVS version
Peter Eisentraut <[EMAIL PROTECTED]> writes: > This is a very valid concern, and it's been bugging us, too. The problem > is that by default, the majority of users would probably want the Perl and > Python modules to be put in the default place where they're easy to find > for the interpreter. (This is pure speculation. Personally, I certainly > wouldn't do this, in the same way as I don't install libraries in /usr/lib > because it makes it easier for the linker to find.) I agree that that's the right place to put the perl & python modules when doing a pure-default configure: it's reasonable to assume we are installing a production system, and so we should install these modules in the default places. But it's a lot harder to make that argument when doing a configure with a non-default --prefix: we may well be building a playpen installation. In any case there should be a way to suppress automatic installation of these modules. > What we probably want is some configure switch that switches between the > current behaviour and the behaviour you want. I'd suggest --prefix-like options to determine installation locations for the perl and python modules, plus options on the order of --no-install-perl (ie, build it, but don't install it). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Fw: Random strings
"Joe Conway" <[EMAIL PROTECTED]> writes: > > Having said that, I'm not married to the idea that we should provide > access > > to both /dev/random and /dev/urandom. I'd be happy to roll another patch, > > limited to just urandom, and renaming the function if you feel strongly > > about it. (should we move this discussion back to hackers to get a wider > > audience?) There was a long discussion on linux-kernel recently about the difference between 'random' and 'urandom'. The upshot seemed to be that 'urandom' is Good Enough in 99% of the cases, since (as long as the generator is seeded well at startup) attackers would have to break SHA1 in order to predict the output from it. If someone has the resources to do that you're basically screwed anyhow... -Doug -- Free Dmitry Sklyarov! http://www.freesklyarov.org/ We will return to our regularly scheduled signature shortly. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
"Joe Conway" <[EMAIL PROTECTED]> writes: > Well, ISTM the simplest (if not the most efficient) way to do bytea-to-text > would be a function that takes the escaped string value from byteaout, and > creates a text value directly from it. The only danger I can think of is > that very long strings might need to be truncated in length, since the > escaped string could be significantly longer than the binary. > Text-to-bytea should be a straight copy, since nothing that can be > represented as text cannot be represented as bytea. Ugh ... if the conversion functions are not inverses then I think they lose much of their value. I could see doing either of these: 1. Conversion functions based on byteaout/byteain. 2. Bytea to text escapes *only* null bytes, text to bytea treats only "\0" as an escape sequence. Or maybe both, with two pairs of conversion functions. In any case, we have to decide whether these coercion functions should be named after the types --- ie, should they be made invokable as implicit coercions? I'm dubious that that's a good idea; if we do it then all sorts of textual operations will suddenly be allowed for bytea without any explicit conversion, which is likely to do more harm than good. The reason for having a separate bytea type is exactly so that you *can't* apply text ops to it without thinking. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] [PATCHES] to_char and Roman Numeral (RN) bug
On Fri, Aug 31, 2001 at 07:28:50PM -0700, Command Prompt, Inc. wrote: > In documenting the to_char() function for transformation of numbers to > text, I noticed that the "RN" template character sequence was displaying > some unusual behavior; specifically, unless in fill mode (with the "FM" > sequence), it would either return the result of the last query executed > derived from a to_char() result, or what appears to be a garbage pointer > if there was no such last query. You are right it's bug. For the 'RM' in non-fillmode is to_char() quiet. I will fix it for 7.2. > I consider myself a competent programmer, but never having hacked on > Postgres, I'm not 100% sure that this modification is totally correct I check it and if it's good solution we use it. Thanks! Karel PS. Bruce, please, can you apply my previous (31 Aug) patch with to_char() stuff? I want fix this bug in really actual CVS code. Thanks. -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [BUGS] Build problem with CVS version
John Summerfield writes: > To my dismay some components don't honour the "--prefix=/tmp/postgresql" > specification and try to install in some other location. > > I'd much prefer for the perl and python components to install into the > location I specified, and to leave me to discuss with Perl and Python > the question of how to make sure I get the right versions (or even > better, offer a handy hint). This is a very valid concern, and it's been bugging us, too. The problem is that by default, the majority of users would probably want the Perl and Python modules to be put in the default place where they're easy to find for the interpreter. (This is pure speculation. Personally, I certainly wouldn't do this, in the same way as I don't install libraries in /usr/lib because it makes it easier for the linker to find.) What we probably want is some configure switch that switches between the current behaviour and the behaviour you want. Incidentally, some work toward this goal has already been done in the CVS tip. Basically, all I was missing is a good name for the option. For you to proceed you could try the following (completely untested): # for local Python install make install python_moduledir='$(pkglibdir)' python_moduleexecdir='$(pkglibdir)' # (yes, single quotes) # for local Perl install make install mysterious_feature=yes # (seriously) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Postgres is eating my CPU
Postmaster is eating my CPU -- see ps and top output at http://jamesthornton.com/misc/postgres.txt or below (it wraps too much when posting to Google, but my server keeps getting overloaded). As you can see from the ps output, there are several INSERT statements -- these return after restarting Postgres and even rebooting the system. I checked the system log for that server, and there are only ~30 INSERTS over the last ~12 hours (all INSERTs called by AOLserver into the referer_log). Futhermore, I haven't been running any INSERT statements from psql, and no one else has access to this system. Yesterday, I ran "vacuum analyze" for the first time in a long time -- could that have caused this situation? System: Postgres 7.0.3, AOLserver 3.4/OpenACS 3.2.5/Postgres driver 2.0, Linux 7.1 P.S. -- Here's Don Baccus' reply from the OpenACS bboard... This is very strange ... my guess is that for some reason a lock is being held persistently and your processes are spinning on it. This should never (cough) happen. This is one for the PG hackers group, I think - Tom Lane's more likely to be able to give you help here than any of us. -- ps -fU postgres... UIDPID PPID C STIME TTY TIME CMD postgres 1842 1 0 12:41 ?00:00:00 /usr/local/pgsql/bin/postmaster -B 6000 -o -S 2000 -S -D /usr/local/pgsql/data postgres 1872 1842 82 12:41 ?01:06:20 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 1997 1842 0 13:11 ?00:00:02 /usr/local/pgsql/bin/postgres localhost nsadmin james idle postgres 2025 1842 21 13:15 ?00:10:04 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2072 1842 27 13:30 ?00:08:51 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2077 1842 25 13:31 ?00:07:41 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2079 1842 25 13:31 ?00:07:44 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2082 1842 25 13:31 ?00:07:40 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2086 1842 26 13:33 ?00:07:41 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2090 1842 0 13:35 ?00:00:01 /usr/local/pgsql/bin/postgres localhost nsadmin james idle postgres 2122 1842 6 13:41 ?00:01:22 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2131 1842 0 13:41 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin buxs idle postgres 2187 1842 20 13:54 ?00:01:32 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2189 1842 19 13:54 ?00:01:28 /usr/local/pgsql/bin/postgres localhost nsadmin james INSERT postgres 2205 1842 0 13:59 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin buxs idle postgres 2217 1842 0 14:00 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin james idle postgres 2218 1842 0 14:00 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin buxs idle postgres 2219 1842 0 14:00 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin buxs idle postgres 2220 1842 0 14:00 ?00:00:00 /usr/local/pgsql/bin/postgres localhost nsadmin james idle top output for postgres user... 2:19pm up 2:31, 2 users, load average: 3.54, 5.55, 6.03 118 processes: 113 sleeping, 5 running, 0 zombie, 0 stopped CPU states: 195.3% user, 4.6% system, 0.0% nice, 807224.6% idle Mem: 319596K av, 289688K used, 29908K free, 0K shrd, 30884K buff Swap: 658584K av, 12K used, 658572K free 79636K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 2122 postgres 9 0 12300 12M 4560 S31.5 3.8 2:16 postmaster 2072 postgres 9 0 4144 4144 3524 S23.1 1.2 9:40 postmaster 2189 postgres 15 0 4152 4152 3528 R21.2 1.2 2:22 postmaster 2077 postgres 15 0 4152 4152 3532 R18.2 1.2 8:31 postmaster 1872 postgres 9 0 11848 11M 4128 R16.5 3.7 67:14 postmaster 2187 postgres 9 0 4148 4148 3528 S16.1 1.2 2:23 postmaster 2082 postgres 9 0 4144 4144 3524 S15.9 1.2 8:30 postmaster 2079 postgres 9 0 4140 4140 3520 S14.8 1.2 8:39 postmaster 2086 postgres 9 0 4140 4140 3516 S14.2 1.2 8:38 postmaster 2025 postgres 9 0 11800 11M 4084 R11.5 3.6 10:54 postmaster 2090 postgres 9 0 15548 15M 6748 S 1.1 4.8 0:01 postmaster 1842 postgres 8 0 1904 1904 1792 S 0.0 0.5 0:00 postmaster 1997 postgres 9 0 13864 13M 5752 S 0.0 4.3 0:02 postmaster 2131 postgres 9 0 4696 4696 4004 S 0.0 1.4 0:00 postmaster 2205 postgres 9 0 3996 3996 3388 S 0.0 1.2 0:00 postmaster 2217 postgres 9 0 11164 10M 3544 S 0.0 3.4 0:00 postmaster 2218 postgres 9 0 11704 11M 3616 S 0.0 3.6 0:00 postma
[HACKERS] [PATCHES] to_char and Roman Numeral (RN) bug
Good day,
Sorry to post to this list about a patch, but I seem to be having some
difficult getting on the pgsql-patches list; keep getting an "illegal
command" when I send it "subscribe", for some reason. At any rate:
In documenting the to_char() function for transformation of numbers to
text, I noticed that the "RN" template character sequence was displaying
some unusual behavior; specifically, unless in fill mode (with the "FM"
sequence), it would either return the result of the last query executed
derived from a to_char() result, or what appears to be a garbage pointer
if there was no such last query.
Example output from PostgreSQL 7.1.3:
---
lx=# SELECT to_char(485, 'RN');
to_char
-
UERY :command 1
(1 row)
lx=# SELECT to_char(485, 'FMRN');
to_char
-
CDLXXXV
(1 row)
lx=# SELECT to_char(485, 'RN');
to_char
-
CDLXXXV
(1 row)
lx=# SELECT to_char(1000, 'RN');
to_char
-
CDLXXXV
(1 row)
lx=# SELECT 1, 2, to_char(900, '999');
?column? | ?column? | to_char
--+--+-
1 |2 | 900
(1 row)
lx=# SELECT to_char(485, 'RN');
to_char
-
900
(1 row)
---
Upon looking into src/backend/utils/adt/formatting.c, I noticed that for
RN transforms:
strcpy(Np->inout_p, Np->number_p);
was only being called within the IS_FILLMODE if block. Moving it out, and
above that check seems to correct this behavior, and I've attached Patches
for both today's pgsql CVS snapshot and postgresql-7.1.3. Both compile,
but I've only tested the latter since my data path is not setup for
pre-7.2, and it seems like a fairly small change.
I consider myself a competent programmer, but never having hacked on
Postgres, I'm not 100% sure that this modification is totally correct
(e.g., if there are any strange side-effects from doing this?), since I'm
not even sure what the Np pointers are achieving in this instance. ;) I'm
guessing its copying the actual output result into the output value's
char* pointer, as that would explain the garbage pointer if it was never
copied.
Any explanation would be greatly appreciated, as I'd like to document this
apparent bug correctly.
Regards,
Jw.
--
[EMAIL PROTECTED] - John Worsley @ Command Prompt, Inc.
by way of [EMAIL PROTECTED]
3976a3977
> strcpy(Np->inout_p, Np->number_p);
3979d3979
< strcpy(Np->inout_p, Np->number_p);
3982c3982
< else
---
> else {
3983a3984
> }
3986a3988
> strcpy(Np->inout_p,
>str_tolower(Np->number_p));
3989d3990
< strcpy(Np->inout_p,
str_tolower(Np->number_p));
3992c3993
< else
---
> else {
3993a3995
> }
3978a3979
> strcpy(Np->inout_p, Np->number_p);
3981d3981
< strcpy(Np->inout_p, Np->number_p);
3984c3984
< else
---
> else {
3985a3986
> }
3988a3990
> strcpy(Np->inout_p,
>str_tolower(Np->number_p));
3991d3992
< strcpy(Np->inout_p,
str_tolower(Np->number_p));
3994c3995
< else
---
> else {
3995a3997
> }
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] BIG problem !!:fatal 1:set user id user admin is not in eg shadow
We have postgres running on a linux machine and we connect with 15 winnt 4.0 machines running ACCESS2000 When we change from access 97 to access 2000 we get every 15 minutes following problem after a process query - fatal 1:set user id user admin is not in eg shadow and also after we select --- waiting... have sombody already have this problem on how to solve??? VERY URGENT ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Porting to Native WindowsNT/2000
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: 04 September 2001 06:43 > To: dave Page > Subject: Re: [HACKERS] Porting to Native WindowsNT/2000 > > > I thought this might interest you. > ** Thanks Tom, > "Ken Hirsch" <[EMAIL PROTECTED]> writes: > >>> Three can you start cygwin programs on startup of the system? > > > It's not quite as simple as that. You can run it as a > service under the > SRVANY program, but that doesn't provide > for a clean shut-down. Has anybody > written an NT service > wrapper for Postgresql? > > IIRC, Jason Tishler was working on one awhile back. Check > the mailing list archives. Jason and others have indeed have indeed got it running as a service using Cygwins cygrunsrv program. I'm now using this configuration for pgAdmin hacking on my laptop and it works well. > As far as the general topic goes: this has come up several > times before, and the conclusion has always been that a > native Windows port would require effort (both initial, and > ongoing maintenance) vastly out of proportion to the reward. > > But it occurs to me that it might be useful to provide a > downloadable package that includes both the Postgres server > and as much of Cygwin as you need to run it, all wrapped up > in a nice friendly installer. Jean-Michel Poure and I were discussing this yesterday and were looking into writing a plugin for pgAdmin II that will guide the users through installing minimal Cygwin with PostgreSQL & the IPC-Daemon on their system. The idea is that they download and install pgAdmin which is a simple procedure for the Windows user (== non *nix user) then run a wizard which downloads and sets up the rest for them so they end up with a working PostgreSQL, running as a service, with pgAdmin as the admin front end. We're also looking into a pg_hba.conf editor to make it easier to write and test pg_hba.conf files. Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] ODBC TODO list is way out of date
There is a TODO list at src/interfaces/odbc/TODO.txt which was last updated in 1998. Do any of the things in this list remain to be done? If not, perhaps the file should be removed. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "If any of you lack wisdom, let him ask of God, who gives to all men generously and without reproach, and it will be given to him." James 1:5 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Table vs. row level locks confusion
The following section http://www.ca.postgresql.org/devel-corner/docs/postgres/locking-tables.html titled "Locking and Tables", has two subsections, "Table-level locks" and "Row-level locks". Under table-level locks we find lock names such as RowShareLock and RowExclusiveLock -- are those table-level locks? Under row-level locks we find no specific lock names mentioned. What I wonder is, if I do BEGIN; LOCK table1 IN ROW EXCLUSIVE MODE; what do I lock? The table? A row? Which row? Clarification appreciated. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
Joe Conway writes: > On a related note, are there any other bytea functions we should have in the > backend before freezing for 7.2? The SQL standards has a lot of functions for BLOB... > I was thinking it would be nice to have a > way to cast bytea into text and vice-versa, so that the normal text > functions could be used for things like LIKE and concatenation. Better write a native LIKE function for bytea, now that some parts are threatening to make the text-LIKE function use the locale collating sequence. (Multibyte aware text could also have interesting effects.) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Bytea/Base64 encoders for libpq - interested?
On Mon, Sep 03, 2001 at 08:48:22PM -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Where did we leave this? > > I don't think adding a datatype just to provide base64 encoding is > a wise approach. The overhead of a new datatype (in the sense of > providing operators/functions for it) will be much more than the > benefit. I think providing encode/decode functions is sufficient... > and we have those already, don't we? Agree too. But 1000 "bad" chars encoded by base64 vs. encoded by escape, what is longer and more expensive for transfer between FE and BE? A base64 problem is that encode all chars in string, but in the real usage some data contains "bad" chars occasional only. Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
