On May 27, 2008, at 12:50 PM, Nicolas Williams wrote:
On Mon, May 26, 2008 at 11:20:27AM -0400, D. Richard Hipp wrote:
SQLite already allows three different names for the rowid: rowid,
oid, _rowid_. If all three names are taken, for example if the
user has a table like this:
CREATE
Your example doesn't counter my suggestion at all, which is to use the data
only and not a special rowid. So you put 2 identical rows in a table.
Since rows in a table are unordered, there isn't even an ordinal position
to distinguish the 2 occurrences of that same row. Since they are
Federico Granata wrote:
Your example doesn't counter my suggestion at all, which is to use the data
only and not a special rowid. So you put 2 identical rows in a table.
Since rows in a table are unordered, there isn't even an ordinal position
to distinguish the 2 occurrences of that same
The normal proper way to do what you said is to declare a table like this:
CREATE TABLE person (
person_id INT PRIMARY KEY,
name TEXT,
birthdate DATE
)
In my example, you are using only the normal data, which is the 3 columns
specified, and you are not referring to a
Darren Duncan wrote:
Ralf Junker wrote:
Can you suggest an alternative to a single reserved name to represent the
column which uniquely identifies a database record under any and all
circumstances?
Yes, change the interface to RowID into a routine call rather than a column
name; eg use
Ralf Junker wrote:
Darren Duncan wrote:
Ralf Junker wrote:
Can you suggest an alternative to a single reserved name to represent the
column which uniquely identifies a database record under any and all
circumstances?
Yes, change the interface to RowID into a routine call rather than a
Bradley A. Town wrote:
Ralf Junker wrote:
This alerts me to a potential danger for SQLite managers which must rely on
some means to retrieve THE RowID which uniquely identifies a record for
in-grid table editing. If the RowID name can be hijacked by other columns
and given another
But thinking more about hijacking RowID I am glad this is now a separate
thread. Lack of a reseverd RowID column name to guarantee unambiguous
record operations by general SQLite tools is a potential thread to data
security IMO.
I would very much appreciate if this could be addressed in a
Ralf Junker wrote:
But thinking more about hijacking RowID I am glad this is now a separate
thread.
Lack of a reseverd RowID column name to guarantee unambiguous record
operations
by general SQLite tools is a potential thread to data security IMO.
I think the real problem here is that SQL
Federico Granata wrote:
have you seen here http://www.sqlite.org/autoinc.html ?
Yes, I did. This documentation actually made me realize that the problem is not
an implementation flaw but a design error, IMO. See my other answer in this
thread for more rationale.
Ralf
Darren Duncan wrote:
I think the real problem here is that SQL allows you to have non-distinct
rows in a table, when all rows should be distinct.
SQLite's implicit RowID does not allow non-distinct values (except for NULL,
but this is documented behavior and only maintained for backwards
Ralf Junker wrote:
On a separate note, it is best for one to be able to name a table or column
et al anything one wants, with all the choice of names as you can store in
a text column for user data. Reserved words aren't an issue as long as
entity names are referred to with an
Ralf Junker wrote:
My oversight, sorry for that. I never questioned that SQLite would reject
reserved word column names, but I now see that this is not so.
This alerts me to a potential danger for SQLite managers which must rely on
some means to retrieve THE RowID which uniquely identifies
13 matches
Mail list logo
