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 http://momjian.us
On Tue, 2010-11-23 at 14:48 -0500, Robert Haas wrote:
> On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler
> 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
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.
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler 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 [ { BEFORE | AFT
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 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". ;-
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 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,
On Mon, Nov 22, 2010 at 7:46 PM, Tom Lane wrote:
> Andrew Dunstan 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 repr
Andrew Dunstan 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 buttons.
On 11/22/2010 06:57 PM, Tom Lane wrote:
"David E. Wheeler" 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 abstra
"David E. Wheeler" 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 member, whic
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.
Patch attached.
Best,
David
enum_value.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
14 matches
Mail list logo
