On 18/05/2012 21:30, J.V. wrote:
> update table set varcharid = ''' || tmp_var || '''
Others have answered your question, but there's a problem here too; you
don't need the quotes. This statement should be just:
update table set varcharid = tmp_var;
...assuming that the types match, of course.
On 2012-05-18, J.V. wrote:
> I have a table with a varchar column.
>
> I want to select the distinct values from this column and loop through
> them (using as a variable) in a raise notice statement and also in an
> update statement.
>
> I have not been able to do this trying over 100 things in
As Tom said, you need to declare tmp_var as per the result set coming from
select distinct (value) column.
I gave a try on it.
create or replace function prn_test() returns void as $$
declare
tmp_var test_table.name%type; ///Test_table with name column
which is varchar(20) in my case
b
"J.V." writes:
> for tmp_var in select distinct(value) from mytable where
> value2='literal'
> tmp_var has to be in ' ' ticks or will not work. it is failing on the
> first FOR statment stating: "invalid input syntax for integer:
> "some_distinct_value".
Um, how do you have tmp_var dec
On Fri, Feb 4, 2011 at 1:18 PM, Tom Lane wrote:
> Jon Nelson writes:
>> I thought 'character varying' (aka varchar) sans length was an alias
>> for text. Is it not?
>
> It has the same behavior, but it is a distinct type, so dummy coercions
> are needed.
Are there any performance implications fo
Jon Nelson writes:
> I thought 'character varying' (aka varchar) sans length was an alias
> for text. Is it not?
It has the same behavior, but it is a distinct type, so dummy coercions
are needed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@p
Arjen,
> You do need to be wary of malicious users who put a first name of a
>few hundred megabytes.
yes, but if that "my first name is a video" hits the database, it is
allready to late, isn't it?
If it is open to the public, input should be sanitized WAY earlier;
and for an internal applicatio
On Tue, Sep 21, 2010 at 1:23 PM, Massa, Harald Armin wrote:
> I recommend to use TEXT as type for that kind of columns.
> 99 out of 100 theories about "this value will never be longer then xx
> characters" fail in the long run.
>
> And "text", limited only by PostgreSQLs limits, performs as good
On 9/21/10 1:29 , Terry Lee Tucker wrote:
On Tuesday, September 21, 2010 07:23:45 Massa, Harald Armin wrote:
I recommend to use TEXT as type for that kind of columns.
99 out of 100 theories about "this value will never be longer then xx
characters" fail in the long run.
And "text", limited
On Tuesday, September 21, 2010 07:23:45 Massa, Harald Armin wrote:
> I recommend to use TEXT as type for that kind of columns.
> 99 out of 100 theories about "this value will never be longer then xx
> characters" fail in the long run.
>
> And "text", limited only by PostgreSQLs limits, performs as
I recommend to use TEXT as type for that kind of columns.
99 out of 100 theories about "this value will never be longer then xx
characters" fail in the long run.
And "text", limited only by PostgreSQLs limits, performs as good or
better then varchar(length_limit) The time of "we only can allow n
c
On 21/09/10 10:40, Marcus Engene wrote:
Hi list,
In Oracle I can...
create table a
(
b varchar2(10 chars)
);
...and then, regardless of character encoding and how much space an
ascii character vs a ö takes, 10 characters will fit there.
Is there anything I've misunderstood? How does the rest
This was discussed yesterday and previously. Please read the archives.
There is no positive performance reason to use varchar instead of text.
On 2010-07-22 05:38:14PM +0200, Armand Turpel wrote:
> Hi,
> I know this issue was controversed discussed. Some one see no really
> benefits of using v
Yan Cheng Cheok wrote:
> According to
> http://www.postgresql.org/docs/8.0/interactive/datatype-character.html
>
> I always use TEXT, for column which store text so that I need not to worry on
> text length.
>
> However, in certain situation, I know that my text length will always < 10
> chara
On Thu, Apr 23, 2009 at 01:21:05PM +0200, Ivan Sergio Borgonovo wrote:
> I'll try to rephrase to check if I understood and for reference.
>
> varchar is slower than text since it has to do some "data type
> check".
Yes but no. It is said to be slower because it has to do a
data length check, not
essentially you are trying to store a database in a database, and
that's slow for one.
Second, storing things as varchar is space and index (space)
ineffective - and that's another reason to make things slower.
Third - you need to complicate your logic to retrieve data, and that adds up.
text is l
On Thu, 23 Apr 2009 12:00:30 +0200
Karsten Hilbert wrote:
> On Thu, Apr 23, 2009 at 11:33:34AM +0200, Ivan Sergio Borgonovo
> wrote:
>
> > Karsten Hilbert wrote:
> >
> > > On Thu, Apr 23, 2009 at 12:02:13AM +0100, Seref Arikan wrote:
> > >
> > > > I have a set of dynamically composed objects
On Thu, Apr 23, 2009 at 11:33:34AM +0200, Ivan Sergio Borgonovo wrote:
> Karsten Hilbert wrote:
>
> > On Thu, Apr 23, 2009 at 12:02:13AM +0100, Seref Arikan wrote:
> >
> > > I have a set of dynamically composed objects represented in
> > > Java, with string values for various attributes, which
Thanks for elaborating on that Tom. I understand what it means by extension
now.
The reason I looked into it in the first place was because someone at work
said that varchar was an alias for text, which didn't quite sound right.
And I had automatically used the data-type "text" for any varying te
Thom Brown writes:
> The reason I ask is because the documentation says "If character varying is
> used without length specifier, the type accepts strings of any size. The
> latter is a PostgreSQL extension." I wasn't sure if such an extension meant
> there was a level of over-head involved, or r
I see. Thanks for clarifying!
Thom
2009/1/27 Richard Huxton
> Thom Brown wrote:
> > The reason I ask is because the documentation says "If character varying
> is
> > used without length specifier, the type accepts strings of any size. The
> > latter is a PostgreSQL extension." I wasn't sure i
Thom Brown wrote:
> The reason I ask is because the documentation says "If character varying is
> used without length specifier, the type accepts strings of any size. The
> latter is a PostgreSQL extension." I wasn't sure if such an extension meant
> there was a level of over-head involved, or red
The reason I ask is because the documentation says "If character varying is
used without length specifier, the type accepts strings of any size. The
latter is a PostgreSQL extension." I wasn't sure if such an extension meant
there was a level of over-head involved, or reduced its indexability.
20
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Rob Richardson wrote:
>> Are there other reasons to use
>> varchar(64) instead of varchar?
> You can't have "varchar" without a length in parentheses,
> as far as I know.
That's what the spec says and that's what some other implementations
require, bu
Rob Richardson wrote:
> The database we install at our customers as part of our
> product includes an event_history table. For some reason
> lost in the mists of time, the most important field in that
> table, the description, is a varchar field specified to be
> only 64 characters long. This
Well, I would guess that whoever designed the DB structure was used to
non-Postgres databases. First see
http://www.postgresql.org/docs/8.3/static/datatype-character.html
for the tip in Para. 7 on that page.
Most Data Bases DO require much more effort (i.e. don't run as fast)
if you use unlimit
Ow Mun Heng wrote:
Anyhow, searching the archives (in my mail client - no internet at the
moment), I see references that when I use TEXT, I will create TOAST
tables which will have them lie _outside_ of my main data table.
The same is true of varchar, and quite a few other data types. There's
On Tue, Apr 29, 2008 at 09:36:31AM +0200, Pascal Cohen wrote:
> I am with 8.3.1 release but I mentioned that this appears with spaces at
> then end not with standard chars. Of course your examples are working
> fine but insert something like 'abc' (with several spaces and it
> will work
Guillaume Lelarge wrote:
Pascal Cohen a écrit :
I had a look in previous posts in the forum but could not find the
answer I was looking for.
My question is should I switch from varchar to text.
We have "discovered" although it seems to be SQL that adding
something like 'text ' to
Pascal Cohen a écrit :
I had a look in previous posts in the forum but could not find the
answer I was looking for.
My question is should I switch from varchar to text.
We have "discovered" although it seems to be SQL that adding something
like 'text ' to a varchar(50) just silent
On Sunday 20 January 2008 01:07, Tom Lane wrote:
> "Luca Arzeni" <[EMAIL PROTECTED]> writes:
> > Is there any way to consider blanks meaningfull AND sort properly locale
> > specific vowels ?
>
> This isn't a Postgres question, it's a locale question. (If you try,
> you'll find that sort(1) sorts
On Jan 15, 2008 6:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>Luca Arzeni <[EMAIL PROTECTED]> writes:
>> That is: the sort order in postgres 8.1.9 seems to ignore the blank.
>
>This is expected behavior in most non-C locales.
>Try "initdb --locale=C".
>
On Jan 15, 2008 6:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Luca Arzeni <[EMAIL PROTECTED]> writes:
> > That is: the sort order in postgres 8.1.9 seems to ignore the blank.
>
> This is expected behavior in most non-C locales.
>
> > In all cases I'm using locale LATIN9 during DB creation, but I
Hello,
you have to use correct localses for your encoding and country:
for czech and utf8 is
cs_CZ.UTF8 ..
for latin2 is
cs_CZ.latin2 etc
czech sorting has more exception and it works
caa
čaa
daa
cha ... it is well for czech
iaa
On 20/01/2008, Luca Arzeni <[EMAIL PROTECTED]> wrote:
> On Ja
"Luca Arzeni" <[EMAIL PROTECTED]> writes:
> Is there any way to consider blanks meaningfull AND sort properly locale
> specific vowels ?
This isn't a Postgres question, it's a locale question. (If you try,
you'll find that sort(1) sorts the same as we do in any given locale.)
I imagine you could
On Jan 15, 2008 6:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>Luca Arzeni <[EMAIL PROTECTED]> writes:
>> That is: the sort order in postgres 8.1.9 seems to ignore the blank.
>
>This is expected behavior in most non-C locales.
>Try "initdb --locale=C".
>
On Tue, 2008-01-15 at 16:32 +0100, Luca Arzeni wrote:
> In all cases I'm using locale LATIN9 during DB creation, but I tested also
> with ASCII, UTF8 and LATIN1 encoding.
I guess this has nothing to do with the encoding, but with the collation
rules used, which is governed by "lc_collate" paramet
Luca Arzeni <[EMAIL PROTECTED]> writes:
> That is: the sort order in postgres 8.1.9 seems to ignore the blank.
This is expected behavior in most non-C locales.
> In all cases I'm using locale LATIN9 during DB creation, but I tested also
> with ASCII, UTF8 and LATIN1 encoding.
LATIN9 isn't a loc
Gustavo Tonini wrote:
Someone have a function that converts a string literal (a varchar
argument) to an integer array?
It isn't clear from your question if you want this:
select string_to_array('1,2,3'::varchar,',')::int[];
string_to_array
-
{1,2,3}
(1 row)
or this:
select
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Basically it looks like planner makes better use of
> WHERE ... IS NOT NULL indexes if either you explicitly
> put "text" as a column type or that you cast the column
> to ::text when making index.
I've applied a patch for this.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Running it myself I do see the same behaviour in 8.3. I'm not sure whether
> this is something we expect to work or not though.
It looks like it might be relatively easy to fix, but I haven't dug down
to find exactly where things go wrong. Presumably th
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> If I may suggest it -- try to run the queries yourself. You will find the
> problem lies not in the statistics.
I was more concerned that there might be other discrepancies between the
commands in the email and the actual commands you're running.
R
On 7/24/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Now, if we:
>
> # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
>QUERY PLAN
>
--
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Now, if we:
>
> # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
>QUERY PLAN
> ---
> Seq Scan on foo (cost=0
On 7/24/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> ALTER TABLE foo ALTER COLUMN i TYPE text;
> EXPLAIN SELECT * FROM foo WHERE i=17;
> QUERY PLAN
> ---
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> ALTER TABLE foo ALTER COLUMN i TYPE text;
> EXPLAIN SELECT * FROM foo WHERE i=17;
> QUERY PLAN
> -
> Bitmap Heap Scan on foo (cost=12.14..554.
Kev <[EMAIL PROTECTED]> writes:
> On Jun 26, 12:16 am, [EMAIL PROTECTED] (Tom Lane) wrote:
>> "Pierre Thibaudeau" <[EMAIL PROTECTED]> writes:
>>> I am puzzling over this issue:
>>> 1) Is there ever ANY reason to prefer "varchar(n)" to "text" as a column
>>> type?
>>
>> In words of one syllable: n
On Jun 26, 12:16 am, [EMAIL PROTECTED] (Tom Lane) wrote:
> "Pierre Thibaudeau" <[EMAIL PROTECTED]> writes:
> > I am puzzling over this issue:
> > 1) Is there ever ANY reason to prefer "varchar(n)" to "text" as a column
> > type?
>
> In words of one syllable: no.
If you have any input from untrust
Paul Lambert wrote:
> Looks like my bad - I created the table initially through pgAdminIII and
> it appears I selected the wrong character varying from the dropdown list.
>
> CREATE TABLE tester
> (
> test_varchar character varying[],
> test_text text
> )
>
> If I change it to character va
Michael Glaesemann wrote:
Works for me:
test=# select version();
version
--
PostgreSQL
Paul Lambert wrote:
> Is there any disk space advantages to using varchar over text? Or will a
> text field only ever use up as much data as it needs.
1. no 2. yes.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"Hackers share the surgeon's secret pleasure in
On Jun 27, 2007, at 19:38 , Paul Lambert wrote:
Is there any disk space advantages to using varchar over text?
No.
Or will a text field only ever use up as much data as it needs.
Yes.
From http://www.postgresql.org/docs/8.2/interactive/datatype-
character.html
The storage requirement
Tom Lane wrote:
"Pierre Thibaudeau" <[EMAIL PROTECTED]> writes:
I am puzzling over this issue:
1) Is there ever ANY reason to prefer "varchar(n)" to "text" as a column type?
In words of one syllable: no.
Not unless you have an application requirement for a specific maximum
length limit (eg
"Pierre Thibaudeau" <[EMAIL PROTECTED]> writes:
> I am puzzling over this issue:
> 1) Is there ever ANY reason to prefer "varchar(n)" to "text" as a column type?
In words of one syllable: no.
Not unless you have an application requirement for a specific maximum
length limit (eg, your client code
On Mon, 25 Jun 2007, Pierre Thibaudeau wrote:
From my reading of the dataype documentation, the ONLY reason I can
think of for using "varchar(n)" would be in order to add an extra
data-type constraint to the column.
That's my understanding as well. I can think of a few reasons to use
char(n)
On Fri, 2007-05-04 at 23:45 +0200, Martijn van Oosterhout wrote:
> On Fri, May 04, 2007 at 03:42:45PM -0400, Tom Lane wrote:
> > It's hardly credible that you could do either strcmp or strcoll in 2 nsec
> > on any run-of-the-mill hardware. What I think is happening is that the
> > compiler is awar
On Fri, May 04, 2007 at 03:42:45PM -0400, Tom Lane wrote:
> It's hardly credible that you could do either strcmp or strcoll in 2 nsec
> on any run-of-the-mill hardware. What I think is happening is that the
> compiler is aware that these are side-effect-free functions and is
> removing the calls e
Jeff Davis <[EMAIL PROTECTED]> writes:
> $ ./cmp
> locale set to: en_US.UTF-8
> strcmp time elapsed: 2034183 us
> strcoll time elapsed: 2019880 us
It's hardly credible that you could do either strcmp or strcoll in 2 nsec
on any run-of-the-mill hardware. What I think is happening is that the
comp
On Fri, 2007-05-04 at 13:52 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I used strcmp() and strcoll() in a tight loop, and the result was
> > indistinguishable.
>
> That's not particularly credible ... were you testing this in a
> standalone test program? If so, did you re
Jeff Davis <[EMAIL PROTECTED]> writes:
> I used strcmp() and strcoll() in a tight loop, and the result was
> indistinguishable.
That's not particularly credible ... were you testing this in a
standalone test program? If so, did you remember to do setlocale()
first? Without that, you'll be in C l
On Thu, 2007-05-03 at 23:08 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > If you're using a non-C locale, it's slower than strcmp() too.
> > PostgreSQL has to do an extra memcpy() in order to use strcoll(),
> > because strings in postgresql aren't necessarily NULL-terminated a
On 5/3/07, Alexander Staubo <[EMAIL PROTECTED]> wrote:
PostgreSQL uses B-trees for its indexes, insertion time is logarithmic
regardless of the type of the key, but strings have a larger overhead
since they involve character comparisons; (i - j) is a lot faster than
strcmp(i, j). If you do go for
Jeff Davis <[EMAIL PROTECTED]> writes:
> If you're using a non-C locale, it's slower than strcmp() too.
> PostgreSQL has to do an extra memcpy() in order to use strcoll(),
> because strings in postgresql aren't necessarily NULL-terminated and
> there's no such thing as strncoll(), unfortunately (a
On Thu, 2007-05-03 at 22:32 +0200, Alexander Staubo wrote:
> On 5/3/07, Matthew Hixson <[EMAIL PROTECTED]> wrote:
> >Is there a significant performance difference between using int
> > primary keys and string primary keys in Postgres?
>
> PostgreSQL uses B-trees for its indexes, insertion time
On 5/3/07, Jeff Davis <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-03 at 08:58 -0700, Matthew Hixson wrote:
> I'm investigating the usage of a UUID primary key generator using
> Hibernate and Postgres. The reason for using a UUID is that we will
> have an application hosted at different sites in d
On 5/3/07, Matthew Hixson <[EMAIL PROTECTED]> wrote:
Is there a significant performance difference between using int
primary keys and string primary keys in Postgres?
PostgreSQL uses B-trees for its indexes, insertion time is logarithmic
regardless of the type of the key, but strings have a
On Thu, 2007-05-03 at 08:58 -0700, Matthew Hixson wrote:
> I'm investigating the usage of a UUID primary key generator using
> Hibernate and Postgres. The reason for using a UUID is that we will
> have an application hosted at different sites in different
> databases. We will need to aggreg
William Garrison wrote:
> I don't recommend it. There are better ways to store UUIDs:
>
> char(32)<-- Easy to work with, fixed length, inefficient
> varchar(32) <-- 4 bytes larger due to variable size
> bytea() <-- 20 bytes, variable length
> bit(128)<-- 16 bytes, optimal
>
> I don't
I don't recommend it. There are better ways to store UUIDs:
char(32)<-- Easy to work with, fixed length, inefficient
varchar(32) <-- 4 bytes larger due to variable size
bytea() <-- 20 bytes, variable length
bit(128)<-- 16 bytes, optimal
I don't like char() or varchar() because of ca
On Nov 5, 2006, at 15:32 , Alain Roger wrote:
I would like to allow web site user to fill a field and for that i
would need a large varchar()...maybe something around 100.000
characters.
i guess that VARCHAR can not hold so many character and that i
should turn to bytea.
Am I right or is t
"Daniel Serodio" <[EMAIL PROTECTED]> writes:
> I've found a thread discussing the use of "text" vs. "varchar"; what
> I'd like to know if there's any performance difference between using
> "varchar(n)" vs. "varchar", ie, should I constrain a "name" column to
> an arbitrary length to improve perform
>Scott Marlowe <[EMAIL PROTECTED]>
wrote on 08/07/2006 12:18:17 PM:
>
> Just FYI, text and varchar are, internally, pretty
much the same types.
> varchar has an optional precision setting as in varchar(200) while
text
> does not allow one.
>
> All the text ops are written for text types, so varc
On Mon, 2006-08-07 at 14:11, [EMAIL PROTECTED] wrote:
> >"Uwe C. Schroeder" <[EMAIL PROTECTED]> wrote on 08/07/2006 11:30:28 AM:
> > Well, you cast all those fields to be concatenated to text. Why
> should the db
> > make a varchar out of that? I seriously doubt that 7.x made a
> varchar of that
>"Uwe C. Schroeder" <[EMAIL PROTECTED]>
wrote on 08/07/2006 11:30:28 AM:
> Well, you cast all those fields to be concatenated to text. Why should
the db
> make a varchar out of that? I seriously doubt that 7.x made a varchar
of that
> - but then, 7.2 is very very old.
> So either cast your field
"Uwe C. Schroeder" <[EMAIL PROTECTED]>
wrote on 08/07/2006 11:30:28 AM:
> Well, you cast all those fields to be concatenated to text. Why should
the db
> make a varchar out of that? I seriously doubt that 7.x made a varchar
of that
> - but then, 7.2 is very very old.
> So either cast your field
Rodrigo Gonzalez <[EMAIL PROTECTED]> wrote
on 08/07/2006 11:41:52 AM:
> SELECT b.ltname, ((c.refullname::text || d.enname::text) ||
> f.evname::text)::varchar AS evlinkname1,
>
This worked, thank you.
*** *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** *** *** *** ***
Margaret Gill
SELECT b.ltname, ((c.refullname::text || d.enname::text) ||
f.evname::text)::varchar AS evlinkname1,
[EMAIL PROTECTED] wrote:
>Rodrigo Gonzalez <[EMAIL PROTECTED]> wrote on 08/07/2006 11:36:28 AM:
> Really, I dont see the 3 varchar fields concatenated to a new field.
>
> But do this
>
> (v
>Rodrigo Gonzalez <[EMAIL PROTECTED]> wrote
on 08/07/2006 11:36:28 AM:
> Really, I dont see the 3 varchar fields concatenated to a new field.
>
> But do this
>
> (varchar1||varchar2||varchar3||newfield)::varchar
>
> Best regards
>
This is the concatenate statement
> > SELECT b.ltname, (c
Well, you cast all those fields to be concatenated to text. Why should the db
make a varchar out of that? I seriously doubt that 7.x made a varchar of that
- but then, 7.2 is very very old.
So either cast your fields to varchar (i.e. c.refullname::varchar ||
d.enname::varchar) or cast the result
Really, I dont see the 3 varchar fields concatenated to a new field.
But do this
(varchar1||varchar2||varchar3||newfield)::varchar
Best regards
[EMAIL PROTECTED] wrote:
Last week I upgraded to postgresql 8.1.4 (YEAH!) In my database I
have a view which concatenates three varchar fields
On Sun, Oct 02, 2005 at 11:37:10AM +0200, Zlatko Mati? wrote:
> There are some columns in my tables that I should change from varchar to
> text, in order to have enough space for long textual commentaries.
> Before I do that, I would like to know is there any restriction regarding
> text type in
On Tue, Jan 04, 2005 at 09:50:18AM +0200, Sim Zacks wrote:
> Are there any differences between text and varchar? I found the following in
> the docs, which leads me to believe that there are no differences at all.
> Can someone please confirm this before I switch all my varchars to text?
Correct.
Hello,
Varchar by default will truncate extra space at the end. If the table
column is defined as char or you cast the varchar to a char data type it
will have a fixed size of 40 characters.
Mike
On Tue, 2004-07-13 at 06:29, Constantin Khatsckevich wrote:
> Hello!
>
> Can I get ordered length
On Mon, 04 Aug 2003 20:07:18 -0400 Tom Lane <[EMAIL PROTECTED]> wrote:
> Richard Welty <[EMAIL PROTECTED]> writes:
> > On Mon, 04 Aug 2003 18:07:49 -0400 Tom Lane <[EMAIL PROTECTED]> wrote:
> >> You don't have to. See CREATE CAST.
>
> > cool. although it does look like there's still a piece miss
I gave up from using ODBC... to much problems with blobs and other stuff...
and really very low speed under Delphi. Try Zeos Database Components for
Postgre(http://www.marms.com/zeos). I've been using for 6 mounths and its
great. Blobs greater than 8Kb still are a big problem, but you will see thi
mitch <[EMAIL PROTECTED]> writes:
> Is there a size limit on indexable varying character fields?
1/3rd page, about 2700 bytes, if you're using btree index.
Presently, TOAST does not help any :-(
regards, tom lane
- Original Message -
From: "Stephan Szabo" <[EMAIL PROTECTED]>
To: "Mitch Vincent" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 1:39 PM
Subject: Re: [GENERAL] varchar => int
>
> Well, you can get there via text (as Peter
87 matches
Mail list logo
