>
> 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
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
>
> 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
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:
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
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;
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
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
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
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
>
> 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
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
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
13 matches
Mail list logo
