Re: functions returning records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, Alex Pilosov <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning records
Date: 2001-06-27 23:03:02
Message-ID: 21587.993682982@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Tom Lane wrote:
>> It seems fairly ugly to have a pg_class entry for something that
>> isn't a table or even a table-like entity.

> I dont think that sequence is any more table-like than record.

Oh? It's got storage, it's got columns, you can select from it.

test71=# create sequence myseq;
CREATE
test71=# select * from myseq;
sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called
---------------+------------+--------------+------------+-----------+-------------+---------+-----------+-----------
myseq | 1 | 1 | 2147483647 | 1 | 1 | 1 | f | f
(1 row)

Looks pretty table-ish to me.

> Also there seems to be more existing creative use of pg_class - what
> does relkind='s' record for pg_variable stand for ?

Special system relation. Again, there's storage behind it (at least for
pg_log, I suppose pg_xactlock is a bit of a cheat... but there doesn't
really need to be a pg_class entry for pg_xactlock anyway, and I'm not
sure pg_log needs one either).

However, this is fairly academic considering the backwards-compatibility
downside of changing pg_attribute.attrelid to pg_attribute.atttypid :-(

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-06-27 23:17:42 Re: pg_largeobject is a security hole
Previous Message Dmitry G. Mastrukov 2001-06-27 22:21:11 Re: New data type: uniqueidentifier