On Tue, Aug 11, 2009 at 4:52 PM, Peter Eisentraut wrote:
> On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
>> The attached patch merges all of the logic currently in genbki.sh and
>> Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl
>
> I can't really convince myself to like this c
Peter Eisentraut escribió:
> On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
> > The attached patch merges all of the logic currently in genbki.sh and
> > Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl
>
> I can't really convince myself to like this change. I think there is so
On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
> The attached patch merges all of the logic currently in genbki.sh and
> Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl
I can't really convince myself to like this change. I think there is some
merit that these scripts are sepa
Peter Eisentraut writes:
> On Sunday 26 July 2009 20:58:30 Tom Lane wrote:
>> The argument about optional stuff doesn't impress me. I would think
>> that something that's going to be optionally loaded doesn't need to be
>> considered during bootstrap mode at all. We can just have initdb run
>> s
On Mon, Jul 27, 2009 at 4:17 AM, Peter Eisentraut wrote:
> On Sunday 26 July 2009 01:40:09 Tom Lane wrote:
>> And it is going to cost us in places like
>> how do we generate the fmgr lookup table.
>
> We rgrep the source tree for PG_FUNCTION_ARGS, extract the function name, and
> put them in a list
On Sunday 26 July 2009 20:58:30 Tom Lane wrote:
> The argument about optional stuff doesn't impress me. I would think
> that something that's going to be optionally loaded doesn't need to be
> considered during bootstrap mode at all. We can just have initdb run
> some SQL scripts (or not) during
On Sunday 26 July 2009 01:40:09 Tom Lane wrote:
> And it is going to cost us in places like
> how do we generate the fmgr lookup table.
We rgrep the source tree for PG_FUNCTION_ARGS, extract the function name, and
put them in a list.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Sun, Jul 26, 2009 at 8:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> Introducing defaults for DATA() would bring some benefits because it
>> would mostly avoid the need to change every row in the file when
>> adding a new column. But a preprocessing script can do much more
>> sophisticated t
Tom Lane escribió:
> I experimented with that a little bit and found it doesn't seem to be
> tremendously easy. A non-bootstrap-mode backend will PANIC immediately
> on startup if it doesn't find the critical system indexes, so the second
> step has issues. Also, there is no provision for resumi
Robert Haas writes:
> On Sun, Jul 26, 2009 at 1:58 PM, Tom Lane wrote:
>> I think we need to try to get *all* of the operator
>> classes out of the hand-maintained-DATA-entries collection.
> Is this mostly a forward-reference problem?
No, I don't see that as particularly the issue. What I'm con
Robert Haas writes:
> Introducing defaults for DATA() would bring some benefits because it
> would mostly avoid the need to change every row in the file when
> adding a new column. But a preprocessing script can do much more
> sophisticated transformations, like computing a value for a column, or
On Sun, Jul 26, 2009 at 1:58 PM, Tom Lane wrote:
> Greg Stark writes:
>> AFAICT the only opclasses that need to be in the bootstrap set are
>> int2_ops, int4_ops, name_ops, oid_ops, and oidvector_ops.
>
> Maybe so, but the first two are part of the integer_ops family. If
> we have to continue imp
On Sun, Jul 26, 2009 at 11:31 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane wrote:
>>> I'm not nearly as excited about migrating all or even most of, say,
>>> the pg_proc DATA lines into SQL.
>
>> I think it would actually buy you quite a bit to migrate the
Greg Stark writes:
> AFAICT the only opclasses that need to be in the bootstrap set are
> int2_ops, int4_ops, name_ops, oid_ops, and oidvector_ops.
Maybe so, but the first two are part of the integer_ops family. If
we have to continue implementing all of that through DATA statements
then we have
On Sun, Jul 26, 2009 at 5:48 PM, Tom Lane wrote:
>
> In the spirit of not inventing single-purpose solutions, I suggest
> that the BKI representation for this might be something like
>
> BKI_EXECUTE( any old SQL command );
>
> where the bootstrap.c code just passes the given string to the main SQL
I wrote:
> ... So maybe we could split the current bootstrap phase
> into three phases:
> * create core catalogs and load DATA commands, using bki
> * create operator classes, using sql script
> * create indexes, using bki
> * proceed on as before
I experimented with that a
Tom Lane wrote:
Robert Haas writes:
On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane wrote:
I'm not nearly as excited about migrating all or even most of, say,
the pg_proc DATA lines into SQL.
I think it would actually buy you quite a bit to migrate them to SQL,
because in SQL,
Robert Haas writes:
> On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane wrote:
>> I'm not nearly as excited about migrating all or even most of, say,
>> the pg_proc DATA lines into SQL.
> I think it would actually buy you quite a bit to migrate them to SQL,
> because in SQL, default properties can genera
On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane wrote:
> I'm not nearly as excited about migrating all or even most of, say,
> the pg_proc DATA lines into SQL. That simply isn't going to buy very
> much in maintainability --- a patch that wants to add a new property
> to all the functions is going to co
[ dept. of second thoughts ]
I wrote:
> It's easy to make that claim, much less easy to actually do it.
Reflecting on this a bit more ... it seems to me that it's not the right
thing to set the goal as "try to get rid of as many DATA statements as
possible". The right way to think about this is
Greg Stark writes:
> Move a lot of those DATA lines to SQL initdb scripts. Virtually all of
> pg_proc, pg_operator, pg_opclass, pg_opfamily, pg_cast, etc can be
> initialized using SQL. Hardly any of the records in there are needed
> for bootstrapping.
It's easy to make that claim, much less easy
On Sat, Jul 25, 2009 at 9:17 PM, Robert Haas wrote:
> Of course, fixing the Anum and
> Natts declarations does not come close to fixing this problem: for
> catalogs that are initialized with any data at bootstrap time, the
> DATA() lines are a much bigger issue, but fixing that is going to
> requir
Robert Haas writes:
> On Sat, Jul 25, 2009 at 10:56 AM, Tom Lane wrote:
>> I didn't realize this change was intending to throw all the Anum_
>> constants into a single header file. I am strongly against that
>> on namespace pollution grounds,
> I don't really understand this objection.
It's for
On Sat, Jul 25, 2009 at 10:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentraut wrote:
>>> I think a less invasive change would be to include anum.h into all the
>>> catalog/pg_*.h headers, so that the external interface stays the same.
>
>> Gah. I wis
Robert Haas writes:
> On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentraut wrote:
>> I think a less invasive change would be to include anum.h into all the
>> catalog/pg_*.h headers, so that the external interface stays the same.
> Gah. I wish a toplevel make would build "contrib".
> Anyway, yeah,
On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentraut wrote:
> On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
>> The attached patch merges all of the logic currently in genbki.sh and
>> Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl. It
>> then extends that logic to generate all o
On Tuesday 30 June 2009 06:59:51 Robert Haas wrote:
> The attached patch merges all of the logic currently in genbki.sh and
> Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl. It
> then extends that logic to generate all of the Anum_* and Natts_*
> constants, as well as the Schema_pg
27 matches
Mail list logo
