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
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
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 identifiers to be
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,
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
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
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 length of
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
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
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 significant
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 be
11 matches
Mail list logo
