Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97666 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7070 invoked from network); 10 Jan 2017 18:04:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2017 18:04:43 -0000 Authentication-Results: pb1.pair.com header.from=adambaratz@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=adam.baratz@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.68 as permitted sender) X-PHP-List-Original-Sender: adam.baratz@gmail.com X-Host-Fingerprint: 209.85.214.68 mail-it0-f68.google.com Received: from [209.85.214.68] ([209.85.214.68:33322] helo=mail-it0-f68.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/56-55699-83225785 for ; Tue, 10 Jan 2017 13:04:41 -0500 Received: by mail-it0-f68.google.com with SMTP id c20so13508957itb.0 for ; Tue, 10 Jan 2017 10:04:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mtcMPb3JZwxmO81xIEqvsR3CMjy6PKGnVvbXM1IyO4U=; b=Rd+Kk1v1JbBvCv8NNcqQFxOsxLXjPQupWJ++v+WWotRoAzOXfeFrkf+iXyOA4licW5 SEzQhR86dgxuhM9IWX9674b91jxycaanKQkeEmOOsVpf2mvK5up1ukc4KopoVVviVCq3 lq52eShAEUMmtIwqOYilhmHYYMCiUsXIJueLwxQ+BPGDMhprQMhi5OcV+bUQaIzMA+Qi B0A6S6RSZP0i4ZarJsJie6pmkClg6OGS4a64Mo+zGSHO/L4c1tOohKhXAr3uoU/jAY8+ q68llmyovAaIjQ/ZZ8wvHHpbx8XCQSCa+hfxvr61KXxnmlUjNFbwj0se2rpbStER3bhH 4ZGg== X-Gm-Message-State: AIkVDXLuOy6WiuLw9kYpuDCe0r3FZvfAcoymzsWgad0BDVHOX9Q5WZwKLUsr3DQRbRBHnQ== X-Received: by 10.36.130.131 with SMTP id t125mr4228587itd.49.1484071477906; Tue, 10 Jan 2017 10:04:37 -0800 (PST) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id j96sm1618721ioo.29.2017.01.10.10.04.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 10:04:37 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id j18so64405842ioe.2 for ; Tue, 10 Jan 2017 10:04:36 -0800 (PST) X-Received: by 10.107.142.210 with SMTP id q201mr4365186iod.31.1484071476611; Tue, 10 Jan 2017 10:04:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.146.10 with HTTP; Tue, 10 Jan 2017 10:04:36 -0800 (PST) In-Reply-To: <000501d26b51$d1119880$7334c980$@marcodor.com> References: <02dc01d26850$eb4e3810$c1eaa830$@belski.net> <001001d26852$6bf9ddb0$43ed9910$@marcodor.com> <000501d26b51$d1119880$7334c980$@marcodor.com> Date: Tue, 10 Jan 2017 13:04:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Dorin Marcoci Cc: marius adrian popa , Anatol Belski , PHP Developers Mailing List Content-Type: multipart/alternative; boundary=94eb2c05c3002f75be0545c1519f Subject: Re: [PHP-DEV] Dorin Marcoci Added Firebrid native type mapping for integers (smallint, integer, bigint) in PDO_Firebird driver From: adambaratz@php.net (Adam Baratz) --94eb2c05c3002f75be0545c1519f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Unfortunately with current PDO state this is not possible to be done in a > nice way. > Now PDO have defined just these field types: PDO::PARAM_BOOL, > PDO::PARAM_INT, PDO::PARAM_STR, PDO::PARAM_LOB, PDO::PARAM_NULL. > Last one is =E2=80=9Cwrong=E2=80=9D and should be removed. NULL is a stat= e, not a type or > a value. See #73852 bug. > So PDO should be extended with at least PDO::PARAM_FLOAT to add > floats/double mapping. It needs an RFC to be extended. > In plans is to add yet for booleans, Firebird3 bool data type. Column data can be treated differently from parameter types. I went through this exercise with pdo_dblib: https://github.com/php/php-src/blob/master/ext/pdo_dblib/dblib_stmt.c#L254 It's a little clunky to deal with the pointers correctly, but if Firebird reports a type, you might as well honor it. I didn't realize until you posted this change that PDO core would cast to ints in some cases. It made me wonder if that code should deal with other types or whether all type handling should be pushed into the drivers. Definitely a separate topic, though... Regarding additional parameter types, it's on my todo to write up an RFC to cover some ambiguous cases: - Binary data (see https://bugs.php.net/bug.php?id=3D47982) - Floating point numbers (see https://www.mail-archive. com/internals@lists.php.net/msg89591.html ) - Unicode (touched on with https://www.mail-archive.com/internals@lists.php.net/msg88713.html) My perspective is mainly as someone who works with pdo_dblib. Emulated prepares make a greater degree of control more desirable in some cases. I need to think through how such types would impact other drivers, and I've unfortunately been short on time for the exercise. Adam --94eb2c05c3002f75be0545c1519f--