Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115017 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46079 invoked from network); 22 Jun 2021 10:27:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2021 10:27:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8A98C1804D8 for ; Tue, 22 Jun 2021 03:45:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jun 2021 03:45:27 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id AD5485101324 for ; Tue, 22 Jun 2021 10:45:25 +0000 (UTC) To: internals@lists.php.net References: Message-ID: Date: Tue, 22 Jun 2021 12:45:24 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] [RFC] is_literal From: pierre-php@processus.org (Pierre) Le 22/06/2021 à 11:28, Dan Ackroyd a écrit : > On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >> Should(n't?) PHP add a basic SQL builder class that can be extended for special cases, e.g. different flavors of SQL? >> > No. Or at least not yet. > > This type of thing is much better done in userland, where the api can > evolve at a fast rate, rather than being limited by the fixed release > schedule of PHP. Agreed, PHP is probably not the right place for an SQL builder, there's too many dialects, too many standard or non-standard features, in the end SQL builders almost always end-up being opinionated by its designer's original need, philosophy, or SQL usage habits, and tailored for users which use certain paradigms. An SQL query builder is already business domain tied, in some way. Of course most are very generic, but often don't handle properly SQL advanced or modern features, whereas some other where built for ORMs and such and may a reduced advanced SQL features that fits the original need. I don't wish to see an SQL query builder in PHP core, instead of favoring usage of modern SQL, it'll in my opinion (of course, that's subjective) lower the expectation of people and probably normalize SQL-92 being the only SQL spoken by people writing PHP (just exaggerating a bit). Regards -- Pierre