Skip site navigation (1) Skip section navigation (2)

Re: Data type to use for primary key

From: "Peter Darley" <pdarley(at)kinesis-cem(dot)com>
To: Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Data type to use for primary key
Date: 2004-11-23 14:59:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
	Well, you should still escape any strings you're getting from a web page so
you can ensure you're not subject to a SQL insert attack, even if you're
expecting integers.
Peter Darley

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of
Pierre-Frédéric Caillaud
Sent: Monday, November 22, 2004 3:06 PM
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Data type to use for primary key

> What is the common approach? Should I use directly the product_code as
> my ID, or use a sequantial number for speed? (I did the same for the
> company_id, this is a 'serial' and not the shor name of the customer.
> I just don't know what is usually done.

	Use a serial :
	- you can change product_code for a product easily
	- you can pass around integers easier around, in web forms for instance,
you don't have to ask 'should I escape this string ?'
	- it's faster
	- it uses less space
	- if one day you must manage products from another source whose
product_code overlap yours, you won't have problems
	- you can generate them with a serial uniquely and easily

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

In response to


pgsql-performance by date

Next:From: Bruce MomjianDate: 2004-11-23 15:06:17
Subject: Re: scalability issues on win32
Previous:From: Merlin MoncureDate: 2004-11-23 13:05:27
Subject: Re: scalability issues on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group