Re: Extension Templates S03E11

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Templates S03E11
Date: 2013-12-11 15:43:00
Message-ID: 16228.1386776580@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> The extra catalog tables which store SQL scripts in text columns is one
>> of my main objections to the as-proposed Extension Templates. I view
>> those scripts as a poor man's definition of database objects which are
>> defined properly in the catalog already.

> I have a very hard time to understand this objection.

Why? I think it has considerable force.

> PL/SQL functions are just a SQL script stored as-is in the catalogs.

Those are the exception not the rule.

> Even views are stored in a textual way in the catalogs, albeit in a
> specific pre-processed format,

This is utter nonsense. That representation has nothing to do with
the original text of the CREATE VIEW command, and the fact that we
store it as an ASCII string rather than some binary blob has more to do
with debuggability than anything else. The important point is that we
can (and sometimes do) transform the view to something else based
on semantic understanding of what's in it. And we also have the ability
to figure out what the view depends on, something that is mighty hard
to get out of a text blob. (The fact that we don't have that for SQL
functions is a serious minus of our approach to functions.)

Stephen is concerned that a pure textual representation lacks any deep
semantic understanding of what's in the extension, and I think that's
indeed something to be concerned about. It's perhaps not a 100% show
stopper, but it's something to be avoided unless the benefits of
storing pure text are overwhelming. Which you don't seem to have
convinced people of.

> So while I hear your objection to the "script in catalog" idea Stephen,
> I think we should move forward. We don't have the luxury of only
> applying patches where no compromise has to be made, where everyone is
> fully happy with the solution we find as a community.

You've got that backwards. We do have the luxury of rejecting new
features until people are generally satisfied that the basic design is
right. There's no overlord decreeing that this must be in 9.4.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-12-11 15:59:53 Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Previous Message Simon Riggs 2013-12-11 15:41:45 Re: autovacuum_work_mem