Re: FDW question - how to identify columns to populate in response?
От | Tom Lane |
---|---|
Тема | Re: FDW question - how to identify columns to populate in response? |
Дата | |
Msg-id | 13246.1439586811@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | FDW question - how to identify columns to populate in response? (Bear Giles <bgiles@coyotesong.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: