"Daniel Verite" writes:
> Tom Lane wrote:
>> As of HEAD, it's impossible to select latex output format
>> at all:
>> regression=# \pset format latex
>> \pset: ambiguous abbreviation "latex" matches both "latex" and
>> "latex-longtable"
> Oops!
>> We could fix that by adding a special case
Tom Lane wrote:
> As of HEAD, it's impossible to select latex output format
> at all:
>
> regression=# \pset format latex
> \pset: ambiguous abbreviation "latex" matches both "latex" and
> "latex-longtable"
Oops!
> We could fix that by adding a special case to accept an exact match
>
"Daniel Verite" writes:
> Tom Lane wrote:
>> Pushed. (I simplified the code a bit by using just one state variable,
>> and also made the error message more verbose.)
> Thanks!
I noticed while poking at the csv patch that we'd outsmarted ourselves
with this one. As of HEAD, it's impossible to
Tom Lane wrote:
> Pushed. (I simplified the code a bit by using just one state variable,
> and also made the error message more verbose.)
Thanks!
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
"Daniel Verite" writes:
> Tom Lane wrote:
>> Ugh. Should we not fix the code so that it complains if there's
>> not a unique match? I would bet that the code was also written
>> on the assumption that any abbrevation must be unique.
> Here's a patch making "\pset format" reject ambiguous
Tom Lane wrote:
> > but "one letter is enough" is not true since 9.3 that added
> > "latex-longtable" sharing the same start as "latex", and then
> > 9.5 added "asciidoc" with the same first letter as "aligned".
>
> Yeah, that text has clearly outstayed its welcome.
>
> > When a
On Tue, Nov 06, 2018 at 06:18:37PM +0100, Daniel Verite wrote:
> In both cases using abbreviations in scripts is not a great
> idea. Anyway I will look into the changes required in do_pset to
> implement the error on multiple matches, if that's the preferred
> behavior.
You would also break the
Tom Lane wrote:
> > When a non-unique abbreviation is used, psql uses the first
> > match in an arbitrary order defined in do_pset() by
> > a cascade of pg_strncasecmp().
>
> Ugh. Should we not fix the code so that it complains if there's
> not a unique match? I would bet that the code
"Daniel Verite" writes:
> psql's documentation has this mention about output formats:
> "Unique abbreviations are allowed. (That would mean one letter is enough.)"
> but "one letter is enough" is not true since 9.3 that added
> "latex-longtable" sharing the same start as "latex", and then
>
