(2012/02/28 23:37), Kohei KaiGai wrote:
> 2012年2月28日12:00 Shigeru Hanada:
>> We have three options:
>>
>> a) remove all system columns (posted patch)
>> b) remove system columns other than tableoid
>> c) leave all system columns as is (current 9.2dev)
>>
>> Incidentally, views, which is very simila
Robert Haas writes:
> On Tue, Feb 28, 2012 at 7:00 AM, Shigeru Hanada
> wrote:
>> We have three options:
>>
>> a) remove all system columns (posted patch)
>> b) remove system columns other than tableoid
>> c) leave all system columns as is (current 9.2dev)
>>
>> Incidentally, views, which is ve
2012年2月28日12:00 Shigeru Hanada :
> (2012/02/28 18:08), Thom Brown wrote:
>> If that's something that will likely be introduced in future, then
>> surely we'd want to keep the tableoid column rather than removing it
>> then re-introducing it later?
>
> As background knowledge, currently (9.1 and 9
On Tue, Feb 28, 2012 at 7:00 AM, Shigeru Hanada
wrote:
> We have three options:
>
> a) remove all system columns (posted patch)
> b) remove system columns other than tableoid
> c) leave all system columns as is (current 9.2dev)
>
> Incidentally, views, which is very similar object type to foreign
(2012/02/28 18:08), Thom Brown wrote:
> If that's something that will likely be introduced in future, then
> surely we'd want to keep the tableoid column rather than removing it
> then re-introducing it later?
As background knowledge, currently (9.1 and 9.2dev) foreign tables have
all system col
2012/2/28 Shigeru Hanada :
> (2012/02/27 12:35), Robert Haas wrote:
>> On Sat, Feb 25, 2012 at 3:56 PM, Thom Brown wrote:
> If there seems to be a consensus on removing system column from foreign
> tables, I'd like to work on this issue. Attached is a halfway patch,
> and ISTM there i
(2012/02/27 12:35), Robert Haas wrote:
> On Sat, Feb 25, 2012 at 3:56 PM, Thom Brown wrote:
If there seems to be a consensus on removing system column from foreign
tables, I'd like to work on this issue. Attached is a halfway patch,
and ISTM there is no problem so far.
>>>
>>>
>>>
On Sat, Feb 25, 2012 at 3:56 PM, Thom Brown wrote:
>>> If there seems to be a consensus on removing system column from foreign
>>> tables, I'd like to work on this issue. Attached is a halfway patch,
>>> and ISTM there is no problem so far.
>>
>>
>> I can say that at least PgAdmin doesn't use the
On 14 November 2011 13:07, Thom Brown wrote:
> 2011/11/14 Shigeru Hanada
>>
>> (2011/11/14 11:25), Robert Haas wrote:
>> > My vote is to nuke 'em all. :-)
>>
>> +1.
>>
>> IIRC, main purpose of supporting tableoid for foreign tables was to be
>> basis of foreign table inheritance, which was not i
2011/11/14 Shigeru Hanada
> (2011/11/14 11:25), Robert Haas wrote:
> > My vote is to nuke 'em all. :-)
>
> +1.
>
> IIRC, main purpose of supporting tableoid for foreign tables was to be
> basis of foreign table inheritance, which was not included in 9.1, and
> we have not supported it yet. Othe
(2011/11/14 11:25), Robert Haas wrote:
> My vote is to nuke 'em all. :-)
+1.
IIRC, main purpose of supporting tableoid for foreign tables was to be
basis of foreign table inheritance, which was not included in 9.1, and
we have not supported it yet. Other system columns are essentially
garbage,
On Sun, Nov 13, 2011 at 6:57 PM, Florian Pflug wrote:
> On Nov13, 2011, at 01:38 , Tom Lane wrote:
>> Just a couple hours ago I was wondering why we create system columns for
>> foreign tables at all. Is there a reasonable prospect that they'll ever
>> be useful? I can see potential value in tab
On Nov13, 2011, at 01:38 , Tom Lane wrote:
> Just a couple hours ago I was wondering why we create system columns for
> foreign tables at all. Is there a reasonable prospect that they'll ever
> be useful? I can see potential value in tableoid, but the others seem
> pretty dubious --- even if you
On sön, 2011-11-13 at 00:58 +, Thom Brown wrote:
> Is there a cost to having them there? Could there be tools that might
> break if the columns were no longer available?
Doubtful. Views don't have system columns either.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 13 November 2011 00:38, Tom Lane wrote:
> Thom Brown writes:
>> But xmin on the file_fdw result is odd. Why are these all over the
>> place?
>
> heap_form_tuple initializes the t_choice fields as though for a tuple
> Datum, and file_fdw doesn't change it.
>
> Just a couple hours ago I was won
Thom Brown writes:
> So the ctid is always 2^32-1. Bit weird, but probably explainable.
See ItemPointerSetInvalid.
> But xmin on the file_fdw result is odd. Why are these all over the
> place?
heap_form_tuple initializes the t_choice fields as though for a tuple
Datum, and file_fdw doesn't ch
I notice that there's some weird info coming out of the system columns
on any FDW:
test=# select tableoid, ctid, xmin, xmax, cmin, cmax, * from dict limit 12;
tableoid | ctid | xmin |xmax| cmin | cmax | words
--++--++---+---+--
17 matches
Mail list logo
