Josh Berkus wrote:
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
Or we could call it extraint conclusions. ;-)
I vote for extraint confusions.
--
Bruce Momjian br...@momjian.us
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... original patch. Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFTER }
existing_enum_value ]
So while the term in the SQL statement
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... original patch. Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ {
On Nov 23, 2010, at 11:48 AM, Robert Haas wrote:
So while the term in the SQL statement is VALUE, it's called a label in
the documentation. I think that's confusing. Does anyone else?
Yes. As between the two options, I favor changing the command. And
let's also paint it pink.
Would that
On Tue, 2010-11-23 at 14:48 -0500, Robert Haas wrote:
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler da...@kineticode.com
wrote:
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... original patch. Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new
On 11/22/2010 06:36 PM, David E. Wheeler wrote:
Patch attached.
Thanks, I'll look at this shortly. I think it needs a little bit more,
which I'll do. In particular, we should now avoid using the word 'value'
to refer to the internal representation of an enum - that will just be
confusing.
David E. Wheeler da...@kineticode.com writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace textual label
with textual value. I think of value as meaning some abstract
notion of a particular enum
On 11/22/2010 06:57 PM, Tom Lane wrote:
David E. Wheelerda...@kineticode.com writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace textual label
with textual value. I think of value as
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of textual label, we should say name? But that
doesn't seem like quite le mot juste either. label is actually a
pretty good word for the text representation of an enum value.
Oh my boots and
On Mon, Nov 22, 2010 at 7:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of textual label, we should say name? But that
doesn't seem like quite le mot juste either. label is actually a
pretty good
On Nov 22, 2010, at 4:46 PM, Tom Lane wrote:
Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.
It isn't a very good word for the abstract value, IMO,
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
Or we could call it extraint conclusions. ;-)
--
-- Josh Berkus
PostgreSQL Experts Inc.
On 11/22/10 5:38 PM, Josh Berkus wrote:
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
... original patch. Sorry. Let's not fiddle with the names.
Or we could call it extraint conclusions. ;-)
13 matches
Mail list logo
