FDW question - how to identify columns to populate in response?

Started by Bear Gilesover 10 years ago2 messages
#1Bear Giles
bgiles@coyotesong.com

Hi, I'm working on a FDW for the unix/linux user database - think
/etc/passwd and /etc/group although I'm actually using system calls that
could be quietly redirected to LDAP or other backends. It's easy to create
the FDW and a table associated with it, something like

CREATE TABLE passwd (
name text,
passwd text,
uid int,
...

The problem is the user could decide to reorder or remove columns so I
can't make the assumption that values[0] is always going to be the username.

I have a solution that requires looking at the rel, extracting the atts,
and then doing a loop where I check the attname against all possible values
for each column. Anything that doesn't match is set to null. This isn't too
bad here but it would be a pain if there are many columns.

Is there a cleaner way? I've looked at a number of other FDW
implementations but they are generally mapping columns to columns (so it's
a short bit of lookup code inside the loop), not copying data provided by a
system call.

Thanks,

Bear

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bear Giles (#1)
Re: FDW question - how to identify columns to populate in response?

Bear Giles <bgiles@coyotesong.com> writes:

Hi, I'm working on a FDW for the unix/linux user database - think
/etc/passwd and /etc/group although I'm actually using system calls that
could be quietly redirected to LDAP or other backends. It's easy to create
the FDW and a table associated with it, something like

CREATE TABLE passwd (
name text,
passwd text,
uid int,
...

The problem is the user could decide to reorder or remove columns so I
can't make the assumption that values[0] is always going to be the username.

I have a solution that requires looking at the rel, extracting the atts,
and then doing a loop where I check the attname against all possible values
for each column. Anything that doesn't match is set to null. This isn't too
bad here but it would be a pain if there are many columns.

Is there a cleaner way?

The only thing that comes to mind is that you could probably amortize the
figure-out-the-mapping overhead over multiple tuples. There's surely no
reason to do it more often than once per query; and if that's not
good-enough performance you could think about caching it longer, with some
sort of invalidation logic.

Take a look at src/include/access/tupconvert.h and
src/backend/access/common/tupconvert.c for inspiration, or maybe even code
you can use directly.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers