Re: POC: converting Lists into arrays - Mailing list pgsql-hackers

From Andres Freund
Subject Re: POC: converting Lists into arrays
Date
Msg-id 20190225215104.ds3qvshapclm3wnr@alap3.anarazel.de
Whole thread Raw
In response to Re: POC: converting Lists into arrays  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: POC: converting Lists into arrays  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2019-02-25 13:41:48 -0800, Peter Geoghegan wrote:
> On Mon, Feb 25, 2019 at 1:31 PM Andres Freund <andres@anarazel.de> wrote:
> > > Andres said that he doesn't like the pg_list.h API. It's not pretty,
> > > but is it really that bad?
> >
> > Yes. The function names alone confound anybody new to postgres, we tend
> > to forget that after a few years. A lot of the function return types are
> > basically unpredictable without reading the code, the number of builtin
> > types is pretty restrictive, and there's no typesafety around the choice
> > of actually stored.
> 
> But a lot of those restrictions are a consequence of needing what
> amount to support functions in places as distant from pg_list.h as
> pg_stat_statements.c, or the parser, or outfuncs.c.

Those could trivially support distinguisiong at least between lists
containing pointer, int, oid, or node. But even optionally doing more
than that would be fairly easy. It's not those modules don't currently
know the types of elements they're dealing with?


> If you add a support for a new datatype, where does that leave
> stored rules?

We don't maintain stored rules across major versions (they break due to
a lot of changes), so I don't quite understand that problem.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode
Next
From: Christophe Pettus
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode