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 6/1/05,
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 convi
TABLE
---+---+---
Column | Type
---+---+---
scan_id | bigint
host_ip | character varying(15)
port_num | integer
plugin_id | integer
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 it’s failing. How to handle that?
Thanks
Dinesh Pandey
From: Ramakrishnan
Muralidharan [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 3:11
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 "i
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 look
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 s
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 ind
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 seem
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 pars
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,
On 6/2/05, Richard Huxton 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 story lo
On Thu, Jun 02, 2005 at 13:40:53 +0100,
Richard Huxton 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
> from a logfile
Bruno Wolff III wrote:
On Thu, Jun 02, 2005 at 13:40:53 +0100,
Richard Huxton 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
On Thu, Jun 02, 2005 at 18:00:17 +0100,
Richard Huxton 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 hash can be use
19 matches
Mail list logo
