Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> It's strange to allow identifiers to be of any length in the system
> table when there is no way to create it using normal syntax.
I agree with Tom -- that doesn't seem strange to me at all.
-Neil
---(end of broadcast)--
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> and the identifier x (as all identifiers) can not be too long. Still, one
> can create the function and update the system table by hand to change x to
> a longer name. Doesn't that sound ugly to you?
It has always been, and likely always will be, po
On Tue, 25 Nov 2003, Tom Lane wrote:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > However, in the parser I use IDENT to get the parameter names and already
> > in the lexer the IDENT tokens are truncated to length NAMEDATALEN.
>
> Right. What's the problem?
It's strange to allow identifie
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> However, in the parser I use IDENT to get the parameter names and already
> in the lexer the IDENT tokens are truncated to length NAMEDATALEN.
Right. What's the problem?
regards, tom lane
---(end of b
On Sun, 23 Nov 2003, Tom Lane wrote:
> Actually I'd suggest text[], as there is no good reason to pad the
> array entries to a fixed length.
I've implemented this part now and it stores the paremeter names in the
pg_proc table as a text[] field.
However, in the parser I use IDENT to get the par
On Sun, 23 Nov 2003, Tom Lane wrote:
> I see absolutely no need for the call path to do anything with this
> stuff before it reaches the language handler. All the handlers fetch
> the pg_proc tuple anyway
Even better then!
I've not gotten so far that i've looked much at that code. What I have
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> And the cost will be fairly large for named parameters as well then. On
> the other hand, if one omits the parameter names one would get almost the
> same speed as before (an extra test is needed to see if we have any
> parameter names that needs to
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Is the reason to use name at all in pg "just" about speed, or is there
> some other reason?
Peter already explained it: we like fixed-width fields in system
catalogs so that we can overlay C struct definitions onto the tuples.
This is a fairly signifi
On Sun, 23 Nov 2003, Tom Lane wrote:
> Actually I'd suggest text[], as there is no good reason to pad the
> array entries to a fixed length.
The only reason against is that all other identifiers have this arbitrary
limit. But sure, text[] would work just as well and without any
restriction.
Is t
On Sun, 23 Nov 2003, Peter Eisentraut wrote:
> How will that work in arbitrary procedural languages?
It is passed along to the handler of the language, and if the language
wants, it can insert these into its environment before execution. I plan
to look at the languages pgsql and sql, but any othe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Dennis Bjorklund writes:
>> I'm in the middle of implementing function parameter names.
> So these two reasons make a "namevector" impractical: First, it would
> probably not be in the performance critical path. Second, it would use up
> a fixed leng
Dennis Bjorklund writes:
> I'm in the middle of implementing function parameter names.
How will that work in arbitrary procedural languages?
> Would it be a good idea to create a namevector in the same way as
> oidvector? Would a normal array like name[] be better?
>
> What is the reason for the
I'm in the middle of implementing function parameter names. In pg_proc
the types of the parameters are currently stored as an oidvector, but
how should I store the parameter names?
Would it be a good idea to create a namevector in the same way as
oidvector? Would a normal array like name[] be be
13 matches
Mail list logo
