Fernando Grijalba wrote:
I want to be able to change an int4 from a sequence and store it as
varchar in the database as a hex number.
Is this possible?
Try the to_hex() function - in the Functions and operators chapter of
the manual - Strings section.
--
Richard Huxton
Archonet Ltd
Thank you, I found out after I posted the message.
I did read the docs but must have looked somewhere else and I search
the lists for hex only and it did not bring the answer back. It
wasn't until I search for int4 to hex that I was able to find the
answer.
Thank you again.
Fernando
On
Dinesh Pandey wrote:
I am inserting some log messages in the column data. (Basically I am
inserting records from reading an xml file)
In the PRIMARY KEY, btree (scan_id, host_ip, port_num, plugin_id, severity,
data) data is of type TEXT and can contain long string values.
I'm still not
TABLE
---+---+---
Column | Type
---+---+---
scan_id | bigint
host_ip | character varying(15)
port_num | integer
plugin_id | integer
severity | character varying(50)
data | text
Indexes:
Hi,
One of the columns in primary key is of
type TEXT. I am able to insert with small data, but for around
3000 characters its failing. How to handle that?
Thanks
Dinesh Pandey
From: Ramakrishnan
Muralidharan [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 3:11
PM
Dinesh Pandey wrote:
---+---+---
Column| Type
---+---+---
scan_id| bigint
host_ip| character varying(15)
port_num | integer
plugin_id | integer
I am inserting some log messages in the column data. (Basically I am
inserting records from reading an xml file)
In the PRIMARY KEY, btree (scan_id, host_ip, port_num, plugin_id, severity,
data) data is of type TEXT and can contain long string values.
The question is how to remove this error
To me it seems that the definer of this table missed the concept index ...
or the concept database
One usually looks up data using a key, but if the whole row is the key, what
data shall be looked up.
So short story long: Remove data from your index. The data column seems
like the data to be
Yes I am storing
some error messages in data column, and the PK columns are party
of search criteria.
Thanks
Dinesh Pandey
From: Ramakrishnan
Muralidharan [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 4:44
PM
To: [EMAIL PROTECTED];
pgsql-general@postgresql.org;
On Thu, Jun 02, 2005 at 14:08:54 +0200,
KÖPFERL Robert [EMAIL PROTECTED] wrote:
To me it seems that the definer of this table missed the concept index ...
or the concept database
One usually looks up data using a key, but if the whole row is the key, what
data shall be looked up.
You
On Thu, Jun 02, 2005 at 17:48:47 +0530,
Dinesh Pandey [EMAIL PROTECTED] wrote:
Yes I am storing some error messages in data column, and the PK columns
are party of search criteria.
If you need to be able to search based on the entire stored error message,
than you might try adding an indexed
KÖPFERL Robert wrote:
To me it seems that the definer of this table missed the concept index ...
or the concept database
One usually looks up data using a key, but if the whole row is the key, what
data shall be looked up.
So short story long: Remove data from your index. The data column
Hi,
how would I find out details about for example what constraint was
violated by an insert statement? The SQL state tells me, that a unique
constraint was violated, but it doesn't say which one. I cannot sensibly
react to such errors if I don't know what exactly happened.
I'd like to avoid
Hi,
I've got a table whose records are more less big. There's however jus one
Int-column changed frequently.
According to postgres' MVCC a whole record gets written, even if just one
bit was changed.
I think of splitting the table now in two parts, connected via the former
PK.
so like:
a|b|data
Markus Bertheau [EMAIL PROTECTED] writes:
how would I find out details about for example what constraint was
violated by an insert statement?
You can't, at the moment, except by parsing the text message.
The error fields facility in the FE/BE protocol could be extended
in that direction, and I
On 6/2/05, Richard Huxton dev@archonet.com wrote:
KÖPFERL Robert wrote:
To me it seems that the definer of this table missed the concept index ...
or the concept database
One usually looks up data using a key, but if the whole row is the key, what
data shall be looked up.
So short
On Thu, Jun 02, 2005 at 13:40:53 +0100,
Richard Huxton dev@archonet.com wrote:
Actually, Dinesh didn't mention he was using this for the speed of
lookup. He'd defined the columns as being the PRIMARY KEY, presumably
because he feels they are/should be unique. Given that they are rows
Bruno Wolff III wrote:
On Thu, Jun 02, 2005 at 13:40:53 +0100,
Richard Huxton dev@archonet.com wrote:
Actually, Dinesh didn't mention he was using this for the speed of
lookup. He'd defined the columns as being the PRIMARY KEY, presumably
because he feels they are/should be unique. Given
On Thu, Jun 02, 2005 at 18:00:17 +0100,
Richard Huxton dev@archonet.com wrote:
Certainly, but if the text in the logfile row is the same, then hashing
isn't going to make a blind bit of difference. That's the root of my
concern, and something only Dinesh knows.
Sure it is. Because the
19 matches
Mail list logo
