Re: An Idea for planner hints

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Gregory Stark <gsstark(at)mit(dot)edu>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org, AgentM <agentm(at)themactionfaction(dot)com>
Subject: Re: An Idea for planner hints
Date: 2006-08-17 10:34:26
Message-ID: 8764gry7kd.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

> Gregory Stark wrote:
> > I'm not sure it's worth throwing out the more user-friendly interface
> > we have now but I think it's clear that a table is the obvious
> > "machine-readable format" if you're already sitting in an SQL
> > database... :)
>
> Then again, a table might not be the optimal format for an inherently
> hierarchical structure.

If it were up to me I would just promote ltree to a standard data type and use
that.

On an only tangentially note it seems like the bootstrap sequence could be
split into two steps. The table definitions and the data types, operators, and
operator classes necessary for those table definitions have to be done in some
kind of C bootstrap code as it is now. However much of the bootstrap code now
could be split off into a standard SQL script.

That would save us a ton of headaches in getting OIDs to line up across tables
and make it easier to add new data types with all their associated operators
and operator classes. Worse, new access methods require defining new operator
classes for all the data types you want to support.

It's much easier to just copy paste the CREATE statements and let the SQL
engine assign all the ids and match up all the records.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-08-17 11:47:15 Re: CREATE INDEX ... ONLINE
Previous Message Greg Stark 2006-08-17 09:07:18 Re: Enum proposal / design