Re: ecpg array support, or lack thereof

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>
Subject: Re: ecpg array support, or lack thereof
Date: 2015-02-08 16:09:11
Message-ID: 20150208160911.GA4107@feivel.credativ.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 04, 2015 at 10:07:07AM -0500, Tom Lane wrote:
> Michael Meskes would be the authority on that question, so I've cc'd
> him to make sure he notices this thread ...

Thanks Tom.

> > The leaks were in the code that takes a host variable, and converts it
> > into a string for sending to the server as a query parameter. In
> > particular, it was in code that deals with arrays. However, the fine
> > manual says:
>
> >> SQL-level arrays are not directly supported in ECPG. It is not
> >> possible to simply map an SQL array into a C array host variable.
> >> This will result in undefined behavior. Some workarounds exist,
> >> however.
>
> > That very clearly says that the code that was fixed is not actually
> > supported.
>
> It seems quite possible to me that this manual text is out of date.

It is, at least partly.

> > 1. In timestamp, interval, and date, the array offset is calculated
> > incorrectly:

Same for numeric it seems.

> > 2. The constructed array looks like this (for timestamp):
>
> > array [2005-06-23 11:22:33,2004-06-23 11:22:33]
>
> > That's bogus. It's sent as a query parameter, not embedded into an SQL
> > string, so the syntax should be '{...}'.

Right. Now I can imagine that this is due to changes over the years. What worries my, though, is that this was fixed for integers, but only for integers, not even for short or long variants thereof. No idea how that happened.

> > It would be nice to fix these, and add a test case to cover all kinds of
> > arrays. Although technically, it works as advertised, because the manual
> > says that it will result in "undefined behaviour".

:)

At the very least it should cover the different types that actually get code copied and pasted.

I'm on it as my time permits.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-02-08 16:31:20 Re: assessing parallel-safety
Previous Message Magnus Hagander 2015-02-08 16:04:17 Re: New CF app deployment