Tom Lane wrote:
> Pushed, thanks.
> BTW, I see we've been spelling your name with an insufficient number
> of accents in the commit logs and release notes. Can't do much about
> the logs, but will fix the release notes.
I use myself the nonaccented version of my name in "From" headers, a
"Daniel Verite" writes:
> Checking http://www.postgresql.org/docs/devel/static/app-psql.html ,
> I notice that the last example is still using the syntax for arguments
> that has been deprecated by commit 6f0d6a507, as discussed in this
> thread.
Ooops.
> A fix to psql-ref.sgml is attached.
Pus
Tom Lane wrote:
> > "Daniel Verite" writes:
> >> To avoid the confusion between "2:4" and "2":"4" or 2:4,
> >> and the ambiguity with a possibly existing "2:4" column,
> >> maybe we should abandon this syntax and require the optional
> >> scolH to be on its own at the end of the command.
Tom Lane wrote:
> I wrote:
> > My feeling is that what we should do is undo the change to use OT_SQLID,
> > and in indexOfColumn() perform a downcasing/dequoting conversion that
> > duplicates what OT_SQLID does in psqlscanslash.l.
>
> Here's an updated patch that does it that way, and al
I wrote:
> My feeling is that what we should do is undo the change to use OT_SQLID,
> and in indexOfColumn() perform a downcasing/dequoting conversion that
> duplicates what OT_SQLID does in psqlscanslash.l.
Here's an updated patch that does it that way, and also adopts Christoph's
documentation s
"Daniel Verite" writes:
> Christoph Berg wrote:
>> If there's no way out, what about changing it the other way, i.e.
>> breaking the case where the column is named by a number? That seems
>> much less of a problem in practice.
> I don't think it would be acceptable.
I had figured it would be ;-)
Christoph Berg wrote:
> If there's no way out, what about changing it the other way, i.e.
> breaking the case where the column is named by a number? That seems
> much less of a problem in practice.
I don't think it would be acceptable.
But there's still the option of keeping the dedicated
Christoph Berg wrote:
> > I don't quite see how to work around that, short of simply
> > removing the possibility of addressing columns by their
> > numbers. [...]
> That would be bad news, given that \crosstabview is meant for
> interactive use where these number shortcuts are much more
Re: Daniel Verite 2016-04-14
> I don't quite see how to work around that, short of simply
> removing the possibility of addressing columns by their
> numbers. Which maybe is a bit sad for the end user, I'm not
> sure, but ISTM that's a logical consequence of abandoning
> the dedicated parser for c
Tom Lane wrote:
> > That would be OK with me; it's certainly less of a hack than what's
> > there now. (I went back and forth about how much effort to put into
> > dealing with the colon syntax; I think the version I have in my patch
> > would be all right, but it's not perfect.)
>
> Her
Re: Tom Lane 2016-04-14 <15673.1460592...@sss.pgh.pa.us>
> Here's a patch along those lines. Any objections?
> \crosstabview [
> colV
> ! [ colH
> ! [ colD
> ! [ scolH
> ! ] ] ] ]
Maybe use "sortcolH" to make it immediately
I wrote:
> "Daniel Verite" writes:
>> To avoid the confusion between "2:4" and "2":"4" or 2:4,
>> and the ambiguity with a possibly existing "2:4" column,
>> maybe we should abandon this syntax and require the optional
>> scolH to be on its own at the end of the command.
> That would be OK with m
Alvaro Herrera writes:
> Tom Lane wrote:
>> (I also took the trouble to make the error messages conform
>> to project style.)
> Not sure about this part. Many psql error messages are full sentences (start
> with uppercase, end in period); others start with the \ command being
> complained about.
"Daniel Verite" writes:
> To avoid the confusion between "2:4" and "2":"4" or 2:4,
> and the ambiguity with a possibly existing "2:4" column,
> maybe we should abandon this syntax and require the optional
> scolH to be on its own at the end of the command.
That would be OK with me; it's certainly
Tom Lane wrote:
> I noticed that the \crosstabview documentation asserts that column name
> arguments are handled per standard SQL semantics. In point of fact,
> though, the patch expends a couple hundred lines to implement what is
> NOT standard SQL semantics: matching unquoted names case-insensi
Tom Lane wrote:
> I noticed that the \crosstabview documentation asserts that column name
> arguments are handled per standard SQL semantics. In point of fact,
> though, the patch expends a couple hundred lines to implement what is
> NOT standard SQL semantics: matching unquoted names cas
I noticed that the \crosstabview documentation asserts that column name
arguments are handled per standard SQL semantics. In point of fact,
though, the patch expends a couple hundred lines to implement what is
NOT standard SQL semantics: matching unquoted names case-insensitively
is anything but t
17 matches
Mail list logo