Re: Regarding varchar max length in postgres

On 10/15/18 8:56 AM, Durgamahesh Manne wrote:
>
>
> On Mon, Oct 15, 2018 at 9:07 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com <mailto:david(dot)g(dot)johnston(at)gmail(dot)com>> wrote:
>
> On Mon, Oct 15, 2018 at 8:24 AM Durgamahesh Manne
> <maheshpostgres9(at)gmail(dot)com <mailto:maheshpostgres9(at)gmail(dot)com>> wrote:
>
> So i need unlimited length data type for required column of the
> table for storing the large values
> is there any issue to use unlimited length datatype  text  for
> the required column of the table instead of using varchar ?
>
>
> Between the two you should use the "text" data type for those
> columns.  You will need to describe your use case in more detail if
> you want input as to whether you need to use the large object API
> instead.
>
> The database cannot store an unlimited amount of data in a single
> row+column (cell) - you will still encounter a physical limit to the
> number of bytes able to be stored in a single cell when using text.
>
> David J.
>
>
>
> Hi sir
>
>  i need to store more values on required column of the table by using
> text  than varchar
>
> you said that physical limit needs to be stored values  in column of the
> table
>
> |text| variable unlimited length

There are two limits at work here. n in varchar(n) and char(n) is the
number of characters that can be stored. Text does not have the ability
to limit the characters on declaration. In the special case of varchar
(no n declared) it is equal to text. All the character types(varchar,
char, text) have a storage limit of 1GB per field. This storage value is
not necessarily a one to one relationship to n as the encoding for the
string maybe a multibyte one and a character may occupy multiple bytes.

>
>
>
> ype
> Thank you for this valuable information
>
>  PostgreSQL is always no 1 world s leading open source  RDBMS
>
>
>
>  I request you all community members to provide built in bdr v3 version
> replication for public as multimaster replication is on high priority
> against other dbms

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com