Re: How to get Relation tuples in C function

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: How to get Relation tuples in C function
Дата
Msg-id CAKU4AWr-T7Gxr0ytZ1q6Ludej8VDqcAoOSu6w1tw3VJHFmUBEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How to get Relation tuples in C function  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: How to get Relation tuples in C function  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers


On Sun, Feb 14, 2021 at 5:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Patrick Handja <patrick.bungama@gmail.com> writes:
> I would like to know if there is a better way to pass a relation or if the
> relation name (CString) as a parameter in a C function and thus be able to
> manipulate its tuples. The documentation is available here:
> https://www.postgresql.org/docs/13/xfunc-c.html#id-1.8.3.13.11. But it is
> not quite clear enough on how to retrieve tuples.

The thing I'd recommend you do is use SPI [1], which lets you execute
SQL queries from inside a C function.  If you don't want to do that
for whatever reason, you need to open the relation, set up a scan,
and fetch tuples from the scan, relying on low-level APIs that tend
to change from version to version.  contrib/pageinspect or
contrib/pgstattuple might offer usable sample code, although with any
prototype you might look at, it's going to be hard to see the forest
for the trees.

                        regards, tom lane

[1] https://www.postgresql.org/docs/current/spi.html


Thank you tom for the reply.  What would be the difference between the
SPI and "write a pure SQL UDF" and call it with DirectFunctionCall1? I
just ran into a similar situation some days before.   Currently I think 
DirectFunctionCall1 doesn't need to maintain a connection but SPI has to
do that.


--
Best Regards

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Detecting pointer misalignment (was Re: pgsql: Implementation of subscripting for jsonb)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: 64-bit XIDs in deleted nbtree pages