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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
[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();
23 matches
Mail list logo
