tmpfile

I should have been more clear, I meant a sqlite.conf can configure a program rather than have it apply globally. For example, a config file placed in same directory as its .wal file to tune it for specific instances. That way you don’t need to lookup what “editions” apply which pragmas or settings. With sqlite.conf you can tune your specific database connections by uncommenting the default settings to enable current features/best practices

Why not a .conf file like everything in /etc or postgresql.conf?

I’d like to have interval types for example

   const D = new Temporal()
   const t = new Interval({minutes:5})
   const v = D.add(t)

Or const now = new Temporal();

You could write a pl/pgsql function that does that mapping for you. For example, insert into some_table values (intern(str), …) where intern can insert and return the intern_id from your intern_table. For select statements and joins you could use interned(str) that only does select without insert.

Great article. Side note: his normalization example reminded me how I used to design tables using a numeric primary key thinking they were more performant than strings. But then I’d have a meaningless id which required a join to get the unique value I actually wanted. One day I realized I could use the same unique key in both tables and save a join.

Simple realization. Big payoff

You:

> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.

How do you know as a client the merchant doesn’t have a skimmer embedded in their payment page? Or that they don’t post directly to their servers (whether accidentally or not)? Are the PCI police going to catch them? Maybe they want to store cards to process later and don’t know or care about pci.

The problem is using the same details for every transaction in a loosely authorized way.

In a perfect world the merchant won’t have access to the card details (like with one-time payments) and everything would go thru a provider with a preauthorized payment. But we don’t live in that world right now.

I’m not sure what you’re replying to?

He says:

> You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.

He’s advocating for a more secure one-time way of making a payment.

It would be more secure since it’s one-time and could not be reused even if the merchant didn’t use a pci compliant design

You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack

> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.

No. In best case, you’re giving your payment details to a PSP. A couple years ago NewEgg had a javascript skimmer on their checkout page that harvested all their customers payment details for months. Obviously anyone with access and intent could do the same for any payment page.

The output is apples and oranges tho. Since I was downvoted by someone I'll added a simple example to show the difference between the two interfaces. I shouldn't have assumed anyone here was familiar with the respective representations.

Sample data:

    CREATE TABLE users (user_id serial, name text);
    CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
    CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id;
    INSERT INTO users VALUES (1, 'Bob');
    INSERT INTO users VALUES (2, 'Sally');

SQLITE3 OUTPUT

    sqlite> .schema
    CREATE TABLE users (user_id serial, name text);
    CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
    CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id
    /* user_comment_view(user_id,comment) */;


    sqlite> .schema users
    CREATE TABLE users (user_id serial, name text);


    sqlite> select * from users;
    1|Bob
    2|Sally

POSTGRESQL OUTPUT

    test=# \d
                    List of relations
     Schema |          Name           |   Type   |  Owner   
    --------+-------------------------+----------+----------
     public | comments                | table    | postgres
     public | comments_comment_id_seq | sequence | postgres
     public | user_comment_view       | view     | postgres
     public | users                   | table    | postgres
     public | users_user_id_seq       | sequence | postgres
    (5 rows)


    test=# \d users
                                Table "public.users"
     Column  |  Type   | Collation | Nullable |                Default                 
    ---------+---------+-----------+----------+----------------------------------------
     user_id | integer |           | not null | nextval('users_user_id_seq'::regclass)
     name    | text    |           |          | 


    test=# select * from users;
     user_id | name  
    ---------+-------
           1 | Bob
           2 | Sally
    (2 rows)

Postgres also supports adding + to commands to get additional extended information, eg, \d+. You can also filter by tables (\dt), filter by views (\dv), filter by functions (\df), etc. It's allows much more natural enumeration of the DB which I wish sqlite had as well.

Hopefully others benefit from the improved compile times! I went from 45s builds to 12s.