Jan Wieck wrote:
This is the reason why the setting has to be at least per database and
cannot be changed after DB creation.
I think there's overwhelming consensus that db creation time is the
latest you can specify the canonical name setting for it. There's
probably a good case to be made
scott.marlowe kirjutas T, 27.04.2004 kell 20:43:
> As someone who has discussed this with Tom in the past, I seem to remember
> that there were major issues with handling the system catalogs, because
> internally, the backends treat the identifiers as if they have already
> been quoted.
why no
scott.marlowe wrote:
I think the answer to all of this would require a lot of code being
touched to either make it case fold, costing performance, or the
replacement of the default lower cased catalog with upper cased catalog.
I'm not the one to decide, but it seems to me that this is not a go
On Mon, 26 Apr 2004, Josh Berkus wrote:
> Shachar,
>
> > I think the concensus was that the runtime part was aprox. four lines
> > where the case folding currently takes place. Obviously, you would have
> > to get a var, and propogate that var to that place, but not actually
> > change program
Josh Berkus wrote:
Shachar,
I think the concensus was that the runtime part was aprox. four lines
where the case folding currently takes place. Obviously, you would have
to get a var, and propogate that var to that place, but not actually
change program flow.
That's only if you ignore th
Shachar,
> I think the concensus was that the runtime part was aprox. four lines
> where the case folding currently takes place. Obviously, you would have
> to get a var, and propogate that var to that place, but not actually
> change program flow.
That's only if you ignore the system catalogs
Josh Berkus wrote:
I also didn't follow the discussion of why a client-side implementation was
technically impossible; this seems like the most obvious course to me, and to
have *considerable* benefit.It's also consistent with our other statement
variables, such as datestyle, which are all c
Shachar,
I've been giving this some more thought. Here are my contributions:
> 1. Setting should be on a per-database level. A per-server option is not
> good enough, and a per-session option is too difficult to implement,
> with no apparent justifiable return.
I disagree with this. I think do
On Mon, 26 Apr 2004, Andrew Dunstan wrote:
> Ideas still swirling a bit
Sure, I'm thinking in public as well. Not something you want to do if you
are afraid of being wrong and showing it :-) But I'm not.
> The constraint would in effect be on CASE WHEN quoted THEN name ELSE upper
> (name) END.
Dennis Bjorklund said:
> On Sun, 25 Apr 2004, Andrew Dunstan wrote:
>
>> >> Why do you want two names? Just keep the original casing, and a
>> >> boolean saying if it's quoted or not.
>>
>> Sorry - brain malfunction - yes, original casing plus boolean would
>> work. In effect you could derive the
On Sun, 25 Apr 2004, Andrew Dunstan wrote:
> >> Why do you want two names? Just keep the original casing, and a boolean
> >> saying if it's quoted or not.
>
> Sorry - brain malfunction - yes, original casing plus boolean would
> work. In effect you could derive the canonical form from those tw
I wrote:
Alvaro Herrera wrote:
On Sun, Apr 25, 2004 at 12:23:55PM -0400, Andrew Dunstan wrote:
I don't think we should rush at this. All of these solutions are
based on the existing structures. I have started thinking about a
solution that would involve keeping two versions of catalog n
Alvaro Herrera wrote:
On Sun, Apr 25, 2004 at 12:23:55PM -0400, Andrew Dunstan wrote:
I don't think we should rush at this. All of these solutions are based
on the existing structures. I have started thinking about a solution
that would involve keeping two versions of catalog names: a cano
On Sun, Apr 25, 2004 at 12:23:55PM -0400, Andrew Dunstan wrote:
> I don't think we should rush at this. All of these solutions are based
> on the existing structures. I have started thinking about a solution
> that would involve keeping two versions of catalog names: a canonical
> name and a "n
Shachar Shemesh wrote:
I'm opening a new thread, as the previous one was too nested, and
contained too much emotions.
I'll start by my understanding of a summary of the thread so far. The
solution we are seeking would have to satisfy the following conditions:
1. Setting should be on a per-dat
Rod Taylor wrote:
5. If the identifier is lowercase only, convert it to uppercase only. I
am assuming here that the authors of the client code chose an
uppercase-folding database, so they should know what they are doing when
accessing stuff from the standard offering.
You've just broken on
> I'm not sure you understood me.
Perhaps not, here is what we have:
\c template_db
CREATE TABLE "example" ( "col" integer);
CREATE DATABASE newdb WITH TEMPLATE template_db UPPERCASE IDENTIFIERS;
\c newdb
SELECT "col" FROM "example";
> In short, I don't think this suggestion broke your databa
> 5. If the identifier is lowercase only, convert it to uppercase only. I
> am assuming here that the authors of the client code chose an
> uppercase-folding database, so they should know what they are doing when
> accessing stuff from the standard offering.
You've just broken one of my databas
18 matches
Mail list logo
