hstore ==> and deprecate =>
in [PgSql]
|
From: Tom Lane on 12 Jun 2010 13:21 "David E. Wheeler" <david(a)kineticode.com> writes: > Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an > hstore(text[], text[]) Oh --- now that I look, both that and the hstore => text[] one are new in 9.0, which means it is not too late to reverse course. So at this point the proposal is: * Leave the text => text operator alone for now, but deprecate it, and document/recommend the underlying hstore(text,text) function instead. * Get rid of the new text[] => text[] operator altogether, and provide/document only the underlying hstore(text[], text[]) function. * Rename the new hstore => text[] operator to something else. (I'm not quite sold on Florian's & proposal, but don't have a better idea to offer offhand.) I notice that in 8.4 and before, the function underlying text => text wasn't called hstore() but tconvert(). Which is going to be a serious PITA for anyone who wants to write cross-version-compatible SQL using hstore. Can we do anything about this? I don't think we want to revert to calling it tconvert(). Can we retroactively add the alternate name hstore() to previous versions, and suggest that people do that manually in existing hstore installations? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 12 Jun 2010 13:28 Tom Lane wrote: > I notice that in 8.4 and before, the function underlying text => text > wasn't called hstore() but tconvert(). Which is going to be a serious > PITA for anyone who wants to write cross-version-compatible SQL using > hstore. Can we do anything about this? I don't think we want to revert > to calling it tconvert(). Can we retroactively add the alternate name > hstore() to previous versions, and suggest that people do that manually > in existing hstore installations? In general, I don't think we make enough use of supplying backward-compatible SQL scripts to fix things, so +1. Let's use the object-relational features we have to make things easier for users. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 12 Jun 2010 13:32 On Jun 12, 2010, at 10:21 AM, Tom Lane wrote: > "David E. Wheeler" <david(a)kineticode.com> writes: >> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an >> hstore(text[], text[]) > > Oh --- now that I look, both that and the hstore => text[] one are new > in 9.0, which means it is not too late to reverse course. So at this > point the proposal is: > > * Leave the text => text operator alone for now, but deprecate it, > and document/recommend the underlying hstore(text,text) function > instead. > > * Get rid of the new text[] => text[] operator altogether, and > provide/document only the underlying hstore(text[], text[]) > function. > > * Rename the new hstore => text[] operator to something else. > (I'm not quite sold on Florian's & proposal, but don't have a > better idea to offer offhand.) +1 > I notice that in 8.4 and before, the function underlying text => text > wasn't called hstore() but tconvert(). Which is going to be a serious > PITA for anyone who wants to write cross-version-compatible SQL using > hstore. Can we do anything about this? I don't think we want to revert > to calling it tconvert(). Can we retroactively add the alternate name > hstore() to previous versions, and suggest that people do that manually > in existing hstore installations? +1 Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 14 Jun 2010 13:02 On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "David E. Wheeler" <david(a)kineticode.com> writes: >> Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an >> hstore(text[], text[]) > > Oh --- now that I look, both that and the hstore => text[] one are new > in 9.0, which means it is not too late to reverse course. So at this > point the proposal is: > > * Leave the text => text operator alone for now, but deprecate it, > and document/recommend the underlying hstore(text,text) function > instead. > > * Get rid of the new text[] => text[] operator altogether, and > provide/document only the underlying hstore(text[], text[]) > function. > > * Rename the new hstore => text[] operator to something else. > (I'm not quite sold on Florian's & proposal, but don't have a > better idea to offer offhand.) > > > I notice that in 8.4 and before, the function underlying text => text > wasn't called hstore() but tconvert(). Which is going to be a serious > PITA for anyone who wants to write cross-version-compatible SQL using > hstore. Can we do anything about this? I don't think we want to revert > to calling it tconvert(). Can we retroactively add the alternate name > hstore() to previous versions, and suggest that people do that manually > in existing hstore installations? Here's a patch that removes the text[] => text[] operator - as suggested above - and instead documents hstore(text[], text[]). Barring objections, I will commit this and then start looking at the other portions of this proposal. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
From: Andrew Gierth on 14 Jun 2010 16:35
>>>>> "Tom" == Tom Lane <tgl(a)sss.pgh.pa.us> writes: Tom> But actually, there's another issue here: hstore defines not one Tom> but three => operators: Tom> text => text yields hstore (with 1 element) Tom> text[] => text[] yields hstore (with N elements) Tom> hstore => text[] yields hstore (subset) Tom> It's reasonable to say that the first two are bad design, but Tom> I'm a bit less willing to say that the last one is. What shall Tom> we do with that? I added the second two primarily by analogy with the first; following the existing pattern seemed to be the way to go at the time. If the first (text => text) operator hadn't already been present when I started looking at it, I'd probably have stuck to hstore() for all construction methods rather than defining an operator. Creating operators that take only existing builtin types is obviously a namespace problem in that multiple independent modules might get into trouble by choosing the same operators. Perhaps this should be formalized as some sort of style guideline for module authors? I'm happy with deprecating the first two => in favour of hstore() if that is in line with general opinion. The hstore => text[] slice could be replaced by another operator name; the existing name comes from the analogy that (hstore -> text[]) returns the list of values, whereas (hstore => text[]) returns both the keys and values. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |