Implement access to column meta information in query results

[yrashk]

[yrashk]

I have a use case where I need to figure out column meta-information (count, names, types) at runtime.

Please let me know if you have any suggestions.

[workingjubilee]

Hmm. Why i32 instead of usize or u32? If it's because you wanted to make it easier for interop with various Postgres FFI functions, it should probably be libc::c_int to make that clear. Is it only because Postgres tends to use c_int for indexing?

[yrashk]

I honestly don't remember anymore :) But I'm happy to change this to usize tomorrow, or if it is the only thing blocking this one, feel free to change it to usize in preparation for the merge.

[yrashk]

I've updated the PR to use usize

[yrashk]

I just did it consistently with the rest of SPI interface. Should those interface be updated eventually, too?

On Fri., Oct. 21, 2022, 12:34 p.m. Eric Ridge, @.***> wrote:

@.**** requested changes on this pull request.

In pgx/src/spi.rs https://github.com/tcdi/pgx/pull/732#discussion_r1002126289:

@@ -487,6 +488,52 @@ impl SpiTupleTable { } } }

• /// Returns the number of columns
• pub fn columns(&self) -> usize {

•    match self.tupdesc {
  

•        Some(tupdesc) => unsafe { (*tupdesc).natts as usize },
  

•        None => 0,
  

•    }
  

• }
• /// Returns column type OID
• ///
• /// The ordinal position is 1-based
• pub fn column_type_oid(&self, ordinal: usize) -> Option<PgOid> {

usize should probably be NonZeroUsize.

Not very ergonomic, but no surprising behaviors around zero.

— Reply to this email directly, view it on GitHub https://github.com/tcdi/pgx/pull/732#pullrequestreview-1151461626, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAADREXORJY6NLRUN2VQHLWELV43ANCNFSM6AAAAAAQ4CW5SA . You are receiving this because you authored the thread.Message ID: @.***>

[eeeebbbbrrrr]

I just did it consistently with the rest of SPI interface. Should those interface be updated eventually, too? …

hmm. the various get_datum() functions. Okay, leave it as is. I'd rather not a) be inconsistent, and b) have an API breakage.