On Sun, Dec 14, 2008 at 02:51:24PM -0800, Michal Szymanski wrote:
> On 14 Gru, 20:22, vindex+lists-pgsql-...@apartia.org (Louis-David
> Mitterrand) wrote:
> >
> > I have an 'event' table and an 'event_date' table pointing to it
> > containing (potentially) several event dates (start and (optionnaly
Fantastic - I'll just if/else the query based on db version.
Thanks!
Corey
Tom Lane wrote:
Corey Horton writes:
Is there any known workaround to get this the elements of the
histogram_bounds anyarray in 8.3.5.
It appears that you could explicitly cast to text and thence to text[]:
s
Corey Horton writes:
> Is there any known workaround to get this the elements of the
> histogram_bounds anyarray in 8.3.5.
It appears that you could explicitly cast to text and thence to text[]:
select array_to_string(histogram_bounds::text::text[], '-') from ...
but this might be too ugly for
Is there any known workaround to get this the elements of the
histogram_bounds anyarray in 8.3.5. If not, when might I expect a fix?
Just trying to plan our testing/release schedule of rolling out to 8.3
around this problem.
Thanks,
Corey
Tom Lane wrote:
I wrote:
While we could probabl
Hi,
I have an 'event' table and an 'event_date' table pointing to it
containing (potentially) several event dates (start and (optionnaly)
end) for the event in the past, present and future.
I'm trying to build a query to select the most "relevant" date:
'current' or 'next' or 'last' (by order of
I wrote:
> While we could probably revert just enough of the changes to
> enforce_generic_type_consistency to allow this case again, I wonder
> just how safe that'd really be. It would amount to expecting that
> functions that take anyarray but don't take or return anyelement to
> not only work on
